archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <>
To: Dan Magenheimer <>
Cc: Andrew Morton <>,
	Dave Hansen <>,,,
	Konrad Wilk <>,
	Seth Jennings <>,
	Nitin Gupta <>,
	Nebojsa Trpkovic <>,,
	KAMEZAWA Hiroyuki <>,, Chris Mason <>,
Subject: RE: [PATCH] mm: implement WasActive page flag (for improving cleancache)
Date: Fri, 27 Jan 2012 11:54:36 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <3ac611ee-8830-41bd-8464-6867da701948@default>

On Fri, 2012-01-27 at 09:32 -0800, Dan Magenheimer wrote:
> > From: James Bottomley []
> > What I was wondering was instead of using a flag, could we make the LRU
> > lists do this for us ... something like have a special LRU list for
> > pages added to the page cache but never referenced since added?  It
> > sounds like you can get your WasActive information from the same type of
> > LRU list tricks (assuming we can do them).
> Hmmm... I think this would mean more LRU queues but that may be
> the right long term answer.  Something like?
> 	read but not used yet LRU
> 	readahead but not used yet LRU

What's the difference between these two?  I think read but not used is
some form of readahead regardless of where it came from.

> 	active LRU
> 	previously active LRU

I don't quite understand why you need two queues here, either.  Surely
active is logically at the bottom of the LRU and previously active at
the top (assuming we've separated the unused pages to a different LRU

> Naturally, this then complicates the eviction selection process.
> > I think the memory pressure eviction heuristic is: referenced but not
> > recently used pages first followed by unreferenced and not recently used
> > readahead pages.  The key being to keep recently read in readahead pages
> > until last because there's a time between doing readahead and getting
> > the page accessed and we don't want to trash a recently red in readahead
> > page only to have the process touch it and find it has to be read in
> > again.
> I suspect that any further progress on the page replacement heuristics
> is going to require more per-page data to be stored.  Which means
> that it probably won't work under the constraints of 32-bit systems.
> So it might also make sense to revisit when/whether to allow the
> heuristics to be better on a 64-bit system than on a 32-bit.
> (Even ARM now has 64-bit processors!)  I put this on my topic list
> for LSF/MM, though I have no history of previous discussion so
> this may already have previously been decided.

I've got to say why? on this.  The object is to find a simple solution
that's good enough.  I think separating the LRU list into two based on
once referenced/never referenced might be enough to derive all the
information we need.  Until that theory is disproved, there's not much
benefit to developing ever more complex heuristics.


  reply	other threads:[~2012-01-27 17:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-25 21:58 [PATCH] mm: implement WasActive page flag (for improving cleancache) Dan Magenheimer
2012-01-26 17:28 ` Dave Hansen
2012-01-26 21:28   ` Dan Magenheimer
2012-01-27  0:31     ` Andrew Morton
2012-01-27  0:56       ` Dan Magenheimer
2012-01-27  1:15         ` Andrew Morton
2012-01-27  2:43           ` Dan Magenheimer
2012-01-27  3:33             ` Rik van Riel
2012-01-27  5:15               ` Dan Magenheimer
2012-01-30  8:57                 ` KAMEZAWA Hiroyuki
2012-01-30 22:03                   ` Dan Magenheimer
2012-01-27 13:43             ` James Bottomley
2012-01-27 17:32               ` Dan Magenheimer
2012-01-27 17:54                 ` James Bottomley [this message]
2012-01-27 18:46                   ` Dan Magenheimer
2012-01-27 21:49                     ` James Bottomley
2012-01-29  0:50                       ` Rik van Riel
2012-01-29 22:25                         ` James Bottomley
2012-01-27  3:28         ` Rik van Riel
2012-01-27  5:11           ` Dan Magenheimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).