> One idea would be to have the swap manager logic set so that when it
> reads some swapped-out pages back in, it tries to place them in one or
> more of the following places, as appropriate...
Reading data back in from disk is generally a lose -- it shouldn't have
been swapped out in the first place. That said, 2.1 as it stands swaps
out lots of data it shouldn't *under certain circumstances* (mostly on low
memory machines). Stephen is working code for lazy swap-cache reclaiming,
but he's a little busy right now and it's a bit too late in 2.1 for code
which potentially destablizes the kernel. I think that lazy page
reclaiming will be a big win on low memory machines, and pretty useful on
big machines too.
Some of the other suggestions you made are just not possible under the
current scheme. I've written code that's pretty low overhead, yet makes
reverse page table lookups possible. This will make 'defragmentation'
possible (page table entries tend to be scattered throughout memory
because of demand fill).
None of this will solve the fragmentation issue on its own. In fact,
lazily reclaiming pages will make the problem worse - we have to
reconsider the allocation policy to avoid the problem. Consider that a
request for a single page can cause an order 5 (128K on x86) page to be
broken up into 1 of each lower order. That definately isn't the right
thing to do for a user page allocation if we're running low on
unfragmented memory. So, I'm playing with the allocator to see if other
schemes might work better.
Another aspect of the same problem is memory consumption elsewhere in the
kernel. Dentries are probably the worst aggrivators as an ls or find will
rapidly add to the kernel's use of memory. That wouldn't be a problem if
all dentries had the same lifespan: what's probably happening is that the
dcache grows quickly, then memory needs to be reclaimed, but individual
pages can't be freed as a couple of entries remain used on the page.
Because kernel memory usage gets scattered in with user memory usage,
swapping out user pages doesn't always free up contiguous regions. I'm
hoping that by making swappable vs non-swappable memory allocations tend
to opposite ends of memory that things will improve.
-ben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu