Re: [PATCH] reapswap for 2.4.5-ac10

["Stephen C. Tweedie" <sct@redhat.com>]

Hi,

On Wed, Jun 06, 2001 at 10:21:16PM +1000, Andrew Morton wrote:
> Jonathan Morton wrote:
> > 
> > Interesting observation.  Something else though, which kswapd is guilty of
> > as well: consider a page shared among many processes, eg. part of a
> > library.  As kswapd scans, the page is aged down for each process that uses
> > it.  So glibc gets aged down many times more quickly than a non-shared
> > page, precisely the opposite of what we really want to happen.
> 
> Perhaps the page should be aged down by (1 / page->count)?

The problem, of course, is that the referenced bit is not being
maintained at the same rate for all pages: we set it whenever we see a
mapping for it.  So, in fact, glibc can get aged *up* more than other
pages: because it is in multiple VMs, the swap loop has the chance to
rejuvinate the page more often.

We really want the aging done elsewhere.  Ideally, the VM page
scanning should be maintaining the state of the referenced bit on the
page, but the age manipulation should be done in the inactive-refill
loop.  That way the referenced-bit state would be propagated into the
page age at a uniform rate for all pages.  The difficulty is that the
refill-inactive loop and the try_to_swap_out loops proceed at
different rates, so it's not really possible at the moment to
determine all at once whether or not a page has been referenced in any
way since it was last seen.

Remember also that an unreferenced page gets unlinked from the page
tables in try_to_swap_out, so the presence of multiple inactive links
to glibc won't affect the swapper too much --- once those links have
been passed over once, they will be removed and we won't get extra
aging down done in subsequent passes.

--Stephen
--
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-mm.org/