linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm <linux-mm@kvack.org>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Nick Piggin <npiggin@suse.de>
Subject: Re: [PATCH] Update Unevictable LRU and Mlocked Pages documentation
Date: Fri, 1 Aug 2008 10:06:23 -0400	[thread overview]
Message-ID: <20080801100623.4aae3e37@bree.surriel.com> (raw)
In-Reply-To: <489313AC.3080605@linux-foundation.org>

On Fri, 01 Aug 2008 08:46:20 -0500
Christoph Lameter <cl@linux-foundation.org> wrote:

> Yes I know and I think the rationale is not convincing if the justification
> of the additional LRU is primarily for page migration.

Basically there are two alternatives:

1) treat unevictable pages just like we treat other pages in the
   system, which means we get to use the same code to manipulate
   them, the same code to isolate them (for migrate, etc), the
   same code to keep track of the statistics, etc...

2) treat unevictable pages differently (not put them on a list)
   and have special statistics code, special code to isolate
   them, special code to detect them, etc...

Because pretty much every time we move a page onto or off of the
unevictable list, we also touch the list_head in the page for 
other reasons (typically to add the page to or remove from a normal
LRU list), we thought it would make the most sense to go with the
approach that needs the least amount of special code for the
unevictable pages.

Besides, a locked page is locked - it should go through fewer
list manipulations than the normal file and anon pages ever will,
so if the list manipulation shows up as a bottleneck it will show
up as a bottleneck for the evictable pages first...

-- 
All rights reversed.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2008-08-01 14:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-30 21:13 Lee Schermerhorn
2008-07-31 14:14 ` Christoph Lameter
2008-07-31 14:43   ` Lee Schermerhorn
2008-08-01 13:46     ` Christoph Lameter
2008-08-01 14:06       ` Rik van Riel [this message]
2008-08-01 14:16         ` Christoph Lameter
2008-08-01 14:36           ` Lee Schermerhorn
2008-08-01 15:41             ` Christoph Lameter
2008-08-04 20:05 ` Randy Dunlap

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20080801100623.4aae3e37@bree.surriel.com \
    --to=riel@redhat.com \
    --cc=Lee.Schermerhorn@hp.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux-foundation.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    --cc=npiggin@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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