> Do a lazy single pass at defragmenting just enough main memory. You can
> do that - it's all virtual, anyway. Just copy the memory, update some
> page table somewhere, and voila - a free large block. I'll warrant it's
> faster than waiting for ANY hard drive. You can even invent "good"
> mem-move policies, eg:
>
> 1. Find biggest free block within DMA availible range.
> 2. Move memory from either side out of the way, like up high in the
> memory space where ISA DMA can't happen.
"Move" is the stumbling block here. You don't know what memory regions
(forgot the structure names already *sigh*) use a given physical address
unless you exhaustively check every PTE of every memory region in every
process. Plus the buffer cache.
> 3. Coalesce free blocks.
Isn't that what you've done with 1+2 already?
> This costs slightly more initially than kicking out a random block of
> 128k of cache, but if the average re-read percentage is big enough, it
> may be worth it. This will be affected by the size of what's already in
> cache. It may be a good idea to run a quick cost estimate of doing
> things either way. With lots in cache, you may not care about
> "forgetting". With lots in state, you just might rather defrag some than
> swap.
Again, if it were just "find a medium hunk of free memory and move its
buddies until you get a big hunk", I would've given Linus a patch to
2.1.79.
Keith
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu