Thanks for clarifying this. I'm having a rather hard time figuring
out what the VM code actually does. (There's not a lot of obvious
mechanism/policy separation, and the replacment algorithm seems
to be distributed among several components.)
What is the motivation for systematically preferring to evict mapped
pages rather than swapped pages? Is this based on tests that show
that it works better that way? My intuition would be that a simple
global replacement policy would work better, and the VM system could
be made simpler and easier to enhance. (Also, tags on pages could
be used to modify the replacement policy further back in the
pipeline, in a more modular way---pages would carry with them info
that could be used for prioritization.) I don't know what expertise has
one into the current design, though, and often researchers like me are
unaware of basic facts that implementors know about. (More's the pity.)
Since the system can handle eviction of mmapped pages, I'm wondering
if most of the swap space management code could be removed, and the
mapped file code could be used to handle normal swap duties. (Is
the separate-but-coordinated handling of file buffers, mmapped pages,
and plain swap pages intentional, or an artifact of evolutionary
development?) For my purposes, messing with the replacement policy
is very daunting because there's a lot of interacting code, much
of which I don't quite understand. (Especially with respect to
concurrency and the prioritization of different kinds of buffers.)
I'm wondering if I could simplify it somewhat with a *simple* hack to
bypass some of it; that might not actually make it better, but might
make it easier to experiment with.
-
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/