ST> That would be true if we didn't do the free_page_and_swap_cache trick.
ST> However, doing that would require two passes: once by the swapper, and
ST> once by shrink_mmap(): before actually freeing a page. This actually
ST> sounds like a *very* good idea to explore, since it means that vmscan.c
ST> will be concerned exclusively with returning mapped and anonymous pages
ST> to the page cache. As a result, all of the actual freeing of pages will
ST> be done in shrink_mmap(), which is the closest we can get to a true
ST> self-balancing system for freeing memory.
There are a few other reasons this would be useful as well.
1) It resembles a 2 handed clock algorithm. So there would
be some real page aging functionality. And we could reclaim pages
that we are currently writing to disk.
2) We could remove the swap lock map.
I have wanted to suggest this for a while but I haven't had the time
to carry it through. :(
ST> I'm going to check this out: I'll post preliminary benchmarks and a
ST> patch for other people to test tomorrow. Getting the balancing right
ST> will then just be a matter of making sure that try_to_swap_out gets
ST> called often enough under normal running conditions. I'm open to
ST> suggestions about that: we've never tried that sort of behaviour in the
ST> vm to my knowledge.
We might want to look at the balance between the buffer cache writing and
shrink_mmap. Because that is how those two systems interact already.
Eric
-
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.tux.org/lkml/