From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 30 Mar 2000 18:19:23 -0300 (BRST) From: Rik van Riel Reply-To: riel@nl.linux.org Subject: Re: shrink_mmap SMP race fix In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Andrea Arcangeli Cc: Linus Torvalds , linux-kernel@vger.rutgers.edu, linux-mm@kvack.org, MOLNAR Ingo List-ID: 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/