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 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/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:27 EST