lkml.org 
[lkml]   [1998]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.1.76, nfs client, and memory fragmentation


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


\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.098 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site