> Essentially the new logic is that if we didn't find anything else that
> can easily be free'd, we just prune the _whole_ dcache. That either
> happens very seldom indeed (on my machine ;), or if it happens often it
> just means that the machine is low on memory in which case it is
> entirely reasonable to throw away the dcache aggressively.
That's not been my experience here. I added a printk to monitor the
shrink call, and I see repeated calls at priority 6 draining the dcache
while doing a kernel compile. This is on a 32M machine under no
particular memory stress -- it can easily handle two simultaneous
compiles with only light swapping.
The try_to_free_page logic does make transitions between states even
when memory is not in short supply, whether because the page cache has
been referenced recently or the mapped pages made young. So when it
leaves the "swap_out" state, there's likely memory available in
"shrink_mmap", but the dcache still gets trashed.
At the very least waiting for priority 4 or 3 would allow all of the
states to be checked for memory.
Regards,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html