Re: shrink_mmap SMP race fix

[Rik van Riel <riel@conectiva.com.br>]

On Thu, 30 Mar 2000, Andrea Arcangeli wrote:
> On Thu, 30 Mar 2000, Rik van Riel wrote:
> 
> >What matters is that the pages should spend _enough time_ in the
> >LRU list for them to have a chance to be reclaimed by the original
> >application. If we maintain a too small list, pages don't get
> >enough of a chance to be reclaimed by their application and the
> >"extra aging" benefit is minimal.
> 
> To avoid shrinking the real cache you have to get rid of the swap cache.
> 
> swap_out is just an engine that generate page cache. If you want
> to keep the good cache you have to shrink from the swap cache.
> The swap cache generated by the swap_out engine is by definition
> just old, it was belonging to a not recently accessed pte. So
> it's a very less interesting cache and preserving the very
> interesting page cache is better than preserving the polluting
> swap cache.

The reason to keep the LRU cache (of _unmapped_ pages) fairly
big is to cheaply increase the page aging from one-bit aging
to two-stage aging. That way we can do more precise page aging.

That this works has been demonstrated by the second chance
replacement patchlet that went into 2.2.15pre...

> >> Shrinking the unused swap cache first is the way to go.
> >
> >NOOOOOO!!  The only reason that the current VM behaves decently
> >at all is that all pages are treated equally. We _need_ to reclaim
> 
> I am now talking about theory, I tried that and it worked very better ;).
> See explanation above on why it gives a smooth swap behaviour.
> 
> Anyway I prefer to continue talking about this again when I'll
> have wrote the code so I'll try it out again and you'll play
> with it too.

That might be the better idea since there seems to be some
misunderstanding when talking about it in English :)

> >all pages in the same way and in the same queue because only then
> >we achieve automatic balancing between the different memory uses
> >in an efficient way.
> 
> If the swap cache page is mapped/used (like after shared swapin)
> shrink_mmap is not going to eat it. Only the cache pollution
> generated by the swap_out gets cleaned up. And it gets cleaned
> up in a dynamic lazy way as usual (if somebody fault in the swap
> cache before shrink_mmap eat it only minor fault happens as
> usual).

Point is, we should give the process a good amount of time
to fault their page back in. Otherwise page aging is just
the single NRU bit; in 2.2 we've already seen that that is
just not enough.

regards,

Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.

Wanna talk about the kernel?  irc.openprojects.net / #kernelnewbies
http://www.conectiva.com/		http://www.surriel.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/