Re: 2.1.76, nfs client, and memory fragmentation

Linus Torvalds (torvalds@transmeta.com)
Fri, 2 Jan 1998 01:30:49 -0800 (PST)


On Thu, 1 Jan 1998 kwrohrer@enteract.com wrote:
>
> Based on what I did with Nachos it would take only one page table entry *
> per page of physical memory; (alternately, the order-0 free bitmap [cw]ould
> grow by a factor of sizeof(pointer)), unless you also need a struct task *
> that's not present in the struct page.

Umm? And what do you do after a fork, when the same physical page is
present in multiple page tables?

You need a data structure that is relative to the _virtual_ size of your
memory map, not the physical size. We already have a physical array
(mem_map[]), and if it was a question of just adding a field to that then
the whole issue would be a no-brainer.

But in order to keep track of shared pages (whether they are truly shared
or just COW-shared) you need to essentially have a shadow page table which
contains the linked list of virtual mappings..

> Right now I see it as a cheap and elegant solution to the fragmentation
> problem which involves low-coefficient O(1) work to maintain and one kbyte
> of storage per megabyte of physical memory. My 32M machine can certainly
> trade 32k it can't use when it needs it, for 16k (and larger) fragments
> on demand...

It sounds like "Nachos" was a toy OS that didn't share pages?

Linus