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

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

Perhaps you could write a defragger that builds the reverse page mapping
when it gets invoked, uses it for a while, and then frees the memory
after rebuilding the higher-order pages. The basic idea is that since
memory fragmentation isn't always a problem, there's no need to always
keep the reverse page data structures around (and pay the ongoing time
cost of keeping them up-to-date.) Your defragger might be active only
occasionally and for a few minutes at a time, so it wouldn't be that
costly in the long run to just walk the page tables and build the data
structures you need.

This same approach could be used to improve kswapd -- IMO one of the
shortcomings of the current kswapd is that it has no persistent memory
of what work has been done. Each time a page has to be freed, it has to
look through the memory maps for all of the tasks.


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