While I must admit that I haven't read the code, could
it be that the swap cache 'forgets' about a page when
no process has it mapped?
If so, then this will have caused the severe performance
loss Simon reported, because with a 'serial-forking'
process (which doesn't have the page mapped itself) will
make the swap cache 'forget' the page (the swap cache
may just be pruned a little too easy compared to other
caches) when in fact we need the page over and over
again...
What we want to do now, is find the best possible
solution or workaround to this problem. Andrea's
version is a great workaround; I haven't found a
real solution yet.
I propose that, if nobody comes up with a good
solution, we use Andrea's workaround.
Of course, another 'nice' workaround may be to
have a minimum 10% of memory as a swap-cached
'inactive list' which is LRU pruned. This way
we will still have the page in memory when we
want it back.
For 2.3, we could extend this to true multi-level
aging, whereby pages that are not accessed will
be removed from a processes working set and mapped
in again from the swap cache when we need to.
Buffer and page cache can be second-chance reclaimed
from the same queue we use for the page cache and
the ratio of mapped vs. unmapped user pages could
be set so something nice, say 1:1...
It has the added advantage that kswapd will have to
spend less CPU time reclaiming pages.
Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
-
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/