Messages in this thread | | | Date | Sun, 8 Jun 2008 19:34:20 -0400 | From | Rik van Riel <> | Subject | Re: [PATCH -mm 13/25] Noreclaim LRU Infrastructure |
| |
On Sun, 8 Jun 2008 16:22:08 -0700 Andrew Morton <akpm@linux-foundation.org> 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.
| |