[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ccb76a4d-d453-4faa-93a9-d1ce015255c0@default>
Date: Thu, 26 Jan 2012 16:56:34 -0800 (PST)
From: Dan Magenheimer <dan.magenheimer@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Dave Hansen <dave@...ux.vnet.ibm.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Konrad Wilk <konrad.wilk@...cle.com>,
Seth Jennings <sjenning@...ux.vnet.ibm.com>,
Nitin Gupta <ngupta@...are.org>,
Nebojsa Trpkovic <trx.lists@...il.com>, minchan@...nel.org,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
riel@...hat.com, Chris Mason <chris.mason@...cle.com>
Subject: RE: [PATCH] mm: implement WasActive page flag (for improving
cleancache)
> From: Andrew Morton [mailto:akpm@...ux-foundation.org]
> Subject: Re: [PATCH] mm: implement WasActive page flag (for improving cleancache)
Thanks for the reply!
> On Thu, 26 Jan 2012 13:28:02 -0800 (PST)
> Dan Magenheimer <dan.magenheimer@...cle.com> wrote:
>
> > > I do think it also needs to get cleared on the way in to the page
> > > allocator. Otherwise:
> > >
> > > PageSetWasActive(page);
> > > free_page(page);
> > > ...
> > > another_user_page = get_free_page()
> > > // now cleancache sees the active bit for the prev user
> > >
> > > Or am I missing somewhere it gets cleared non-explicitly somewhere?
> >
> > True, it is not getting cleared and it should be, good catch!
>
> It should be added to PAGE_FLAGS_CHECK_AT_FREE.
I was thinking of clearing it in free_pages_prepare() before the
call to free_pages_check(). Does that make sense? If so, then
it could also be added to PAGE_FLAGS_CHECK_AT_FREE, though it might
be a bit redundant.
> > I'll find the place to add the call to ClearPageWasActive() for v2.
>
> AFAICT this patch consumes our second-last page flag, or close to it.
> We'll all be breaking out in hysterics when the final one is gone.
I'd be OK with only using this on 64-bit systems, though there
are ARM folks playing with zcache that might disagree. Am I
correct in assuming that your "second-last page flag" concern
applies only to 32-bit systems?
> This does appear to be a make or break thing for cleancache - if we
> can't fix https://lkml.org/lkml/2012/1/22/61 then cleancache is pretty
> much a dead duck.
Hmmm... is that URL correct? If so, there is some subtlety in
that thread that I am missing as I don't understand the relationship
to cleancache at all?
> But I'm going to ask for great effort to avoid
> consuming another page flag. Either fix cleancache via other means or,
> much less desirably, find an existing page flag and overload it.
Cleancache isn't broken. The fix is not a requirement for other
cleancache users (Xen and RAMster), though it is definitely useful.
It's not a _requirement_ for zcache either but definitely helps on
certain workloads and systems, see below.
> And I'm afraid that neither I nor other MM developers are likely to
> help you with "fix cleancache via other means" because we weren't
> provided with any description of what the problem is within cleancache,
> nor how it will be fixed. All we are given is the assertion "cleancache
> needs this".
The patch comment says:
The patch resolves issues reported with cleancache which occur
especially during streaming workloads on older processors,
see https://lkml.org/lkml/2011/8/17/351
I can see that may not be sufficient, so let me expand on it.
First, just as page replacement worked prior to the active/inactive
redesign at 2.6.27, cleancache works without the WasActive page flag.
However, just as pre-2.6.27 page replacement had problems on
streaming workloads, so does cleancache. The WasActive page flag
is an attempt to pass the same active/inactive info gathered by
the post-2.6.27 kernel into cleancache, with the same objectives and
presumably the same result: improving the "quality" of pages preserved
in memory thus reducing refaults.
Is that clearer? If so, I'll do better on the description at v2.
Thanks,
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists