Re: [RFC] Tracking mlocked pages and moving them off the LRU

[Matt Mackall <mpm@selenic.com>]

On Mon, Feb 05, 2007 at 09:39:34AM +0100, Arjan van de Ven wrote:
> On Sun, 2007-02-04 at 23:57 -0800, Christoph Lameter wrote:
> > Hmmm.. I have had no time to test this one yet but I think this should 
> > work. It uses the delayed method and a new page flag PageMlocked() with 
> > different semantics. Fix for page migration is also included.
> > 
> > Patch avoids to put new anonymous mlocked pages on the LRU. Maybe the same 
> > could be done for new pagecache pages?
> > 
> > I still need a solution for the problem of not having enough page flag 
> > bits on i386 NUMA.
> 
> I still don't get why you *really* need such a bit. 

There are three possibilities mentioned so far:

1) slow accounting - scan each attached VMA on each mmap/munmap
2) lazy accounting - the same as above, with the work all moved to the
LRU sweep
3) accounting with an extra page flag - still needs to scan VMAs on munmap

Christoph seems to prefer the third.

I wonder if we couldn't stick a rough counter in address_space to
fast-path the slow accounting - we'll typically only have 0 or 1 locks
active.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/