Re: shrink_mmap SMP race fix

From: Andrea Arcangeli (andrea@suse.de)
Date: Thu Mar 30 2000 - 15:41:45 EST


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.

>> 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.

>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).

>It's certainly not bad. In fact, current VM behaviour is good enough
>that I'd rather not touch it before 2.5... In the past we had some
>very bad problems with VM behaviour just before a stable release,
>now things seem to work quite well.

Agreed.

Right now I'm not fully convinced about zone_balance_memory() that is
calling try_to_free_pages for all the zonelist while try_to_free_pages is
supposed to be aware of classzones and to shrink all the inclusive zone
automatically (same for kswapd since it uses the same helper function to
do the page freeing). Currently I can't notice the effect of such code:

  DMA: 399*8kB 293*16kB 247*32kB 226*64kB 81*128kB 122*256kB 129*512kB 60*1024kB
  Normal: = 0kB)
  HighMem: = 0kB)

but it looks the source of the too much swap thing reported to l-k.

Andrea

-
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