Re: [PATCH -mm 13/25] Noreclaim LRU Infrastructure

[Rik van Riel]

On Sun, 8 Jun 2008 16:22:08 -0700
Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:

> The this-is-64-bit-only problem really sucks, IMO.  We still don't know
> the reason for that decision.  Presumably it was because we've already
> run out of page flags?  If so, the time for the larger pageframe is
> upon us.

32 bit machines are unlikely to have so much memory that they run
into big scalability issues with mlocked memory.

The obvious exception to that are large PAE systems, which run
into other bottlenecks already and will probably hit the wall in
some other way before suffering greatly from the "kswapd is
scanning unevictable pages" problem.

I'll leave it up to you to decide whether you want this feature
64 bit only, or whether you want to use up the page flag on 32
bit systems too.

Please let me know which direction I should take, so I can fix
up the patch set accordingly.
 
> > > As a starting point: what, in your english-language-paragraph-length
> > > words, does this flag mean?
> > 
> > "Cannot be reclaimed because someone has it locked in memory
> > through mlock, or the page belongs to something that cannot
> > be evicted like ramfs."
> 
> Ray's "unevictable" sounds good.  It's not a term we've used elsewhere.
> 
> It's all a bit arbitrary, but it's just a label which maps onto a
> concept and if we all honour that mapping carefully in our code and
> writings, VM maintenance becomes that bit easier.

OK, I'll rename everything to unevictable and will add documentation
to clear up the meaning.

-- 
All rights reversed.
--
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/