lkml.org 
[lkml]   [1998]   [Jan]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 2.1.76, nfs client, and memory fragmentation
Date
> > No, no reverse page tables. The data structures to keep them up-to-date
> > worries me (it would essentially involve doubling all the page tables).
>
> One word: Eh?
>
> 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

How do you handle shared pages - you need more than one pointer in this case.

> 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...

Put it this way - Im willing to drop 32K of memory for the right results
and test the patch if you do it. To start with I can get that 32K back
simply by putting Andy's select/poll patches into my kernel and non inlining
the copy_to/from_user which btw my benchmarks say speeds up the machine

Alan


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