Re: patch cow-swapin [was Re: Very bad swap bug -- 2.0, 2.1 at least]

Rik van Riel (H.H.vanRiel@phys.uu.nl)
Thu, 24 Sep 1998 20:02:00 +0200 (CEST)


On Thu, 24 Sep 1998, Andrea Arcangeli wrote:
> On Thu, 24 Sep 1998, Stephen C. Tweedie wrote:
> >It already has a sense. The fact that it can equally be used for
> >other things such as swap readahead doesn't detract from the important
> >functions it already performs.
>
> Yes, it' s useful but it' s not a real cache. It' s not caching. If
> it would just cache nobody would report problems. The most important
> thing that the swap cache could do it' s not done right now
> (2.1.122). Maybe I consider it "the most important thing" only
> because it' s the only one that doesn' t work yet ;-). I don' t
> know...

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/