> 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.
Regards,
Bill