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

[Arjan van de Ven]

On Sat, 2007-02-03 at 09:56 -0800, Christoph Lameter wrote:
> On Sat, 3 Feb 2007, Andrew Morton wrote:
> 
> > I wonder if it can be simpler.  Make two changes:
> 
> Would be great if this could get simpler.
> 
> > a) If the scanner encounters an mlocked page on the LRU, take it off.
> 
> The current patch takes them off when mlock is set (which may not work 
> since the page may be off the LRU) and then has the scanner taking them 
> off. We could just remove the early one but what would this bring us?

it's simpler. You only move them off when you encounter them during a
scan. No walking early etc etc. Only do work when there is an actual
situation where you do scan.

> 
> > b) munlock() adds all affected pages to the LRU.
> 
> Hmmm... You mean without checking all the vmas of a page for VM_LOCKED? So they 
> are going to be removed again on the next pass? Ok. I see that makes it 
> simpler but it requires another reclaim scan.

Well.. That's the point! Only IF there is a reclaim scan do you move
them out again. The fact that these pages are on the list isn't a
problem. The fact that you keep encountering them over and over again
during *scanning* is. So Andrews suggestion makes them go away in the
situations that actually matter

> The page flag allows a clean state transition of a page and accurate 
> keeping of statistics for MLOCKed pages. There were objections against the 
> fuzzy counting in the earlier incarnation and it was proposed that a page 
> flag be introduced. Without the flag we cannot know that the page is 
> already mapped by a VM_LOCKED vma without scanning over all vmas 
> referencing the page.

who cares though.. just do it lazy.


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