From: Rik van Riel <riel@redhat.com>
To: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Elladan <elladan@eskimo.com>,
Peter Zijlstra <peterz@infradead.org>,
Lee Schermerhorn <lee.schermerhorn@hp.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>,
epasch@de.ibm.com, Martin Schwidefsky <schwidefsky@de.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>
Subject: Re: Increased Buffers due to patch 56e49d (vmscan: evict use-once pages first), but why exactly?
Date: Tue, 08 Dec 2009 11:13:59 -0500 [thread overview]
Message-ID: <4B1E7B47.1000707@redhat.com> (raw)
In-Reply-To: <4B1E76C9.50901@linux.vnet.ibm.com>
On 12/08/2009 10:54 AM, Christian Ehrhardt wrote:
> btw thanks for the explanation Rik, the file/blockdev association was
> exactly what I was missing in my thoughts.
> While my question was more intended to ask where in code these
> differentiation is made I'm perfectly fine with having it just working
> knowing that file/blockdev association is the key.
Actually, the file/blockdev association is just a coincidence,
due to the way your benchmark works.
The key is "page touched once" vs "page touched multiple times".
In eg. a database workload, I would expect much more file data
to be on the active list. Specifically the file data corresponding
to the database indexes.
--
All rights reversed.
prev parent reply other threads:[~2009-12-08 16:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-07 14:36 Increased Buffers due to patch 56e49d (vmscan: evict use-once pages first), but why exactly? Christian Ehrhardt
2009-12-07 18:17 ` Rik van Riel
2009-12-08 0:43 ` KOSAKI Motohiro
2009-12-08 15:54 ` Christian Ehrhardt
2009-12-08 16:13 ` Rik van Riel [this message]
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=4B1E7B47.1000707@redhat.com \
--to=riel@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ehrhardt@linux.vnet.ibm.com \
--cc=elladan@eskimo.com \
--cc=epasch@de.ibm.com \
--cc=hannes@cmpxchg.org \
--cc=heiko.carstens@de.ibm.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=lee.schermerhorn@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=schwidefsky@de.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.