From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Cc: Al Boldi <a1426z@gawab.com>, linux-kernel@vger.kernel.org
Subject: Re: [RFC] Limit the size of the pagecache
Date: Thu, 25 Jan 2007 11:29:05 +0100 [thread overview]
Message-ID: <1169720945.6189.52.camel@twins> (raw)
In-Reply-To: <45B86930.2090709@linux.vnet.ibm.com>
> Apart from kswapd, limiting pagecache helps performance of
> applications by not eating away their ANON pages or other parts of its
> resident data set. When there is enough free memory, then there is no
> performance issue. However memory is always utilized to the max.
> Hence every pagecache page that is allocated should come from some
> application's RSS, or from cold pagecache page. If that page was
> stolen from some application, then that application pays the price for
> swapping or reading the page back to memory. This scenario is what we
> want to avoid. All that we are trying to achieve is that pagecache
> eats a (unmapped) pagecache page and not steal memory from other
> important application's resident set.
>
> Certainly this should be a configurable option and kernel's behavior
> should not be changed in general.
Ah, this would be a clear case of the page reclaim selecting the wrong
working set.
It is perfectly fine for a page cache page to evict a app page (be it
anon or not) if that page cache page is used more frequently than the
app page in question.
Trouble seems to be that the current algorithm gets it quite wrong at
times.
Also stating that free memory somehow is good for you is weird, free
memory is a loss, you under utilise your machine. Keeping clean
pagecache pages in there that are likely to be referenced again is a
clear win; it saves the tediously slow load from disk.
So you're now proposing to limit the page cache were as its clear that
the better solution would be to tune replacement policy (and or provide
hints to said mechanism using madvise/fadvise)
next prev parent reply other threads:[~2007-01-25 10:29 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-25 6:42 [RFC] Limit the size of the pagecache Al Boldi
2007-01-25 8:24 ` Vaidyanathan Srinivasan
2007-01-25 10:29 ` Peter Zijlstra [this message]
2007-01-25 11:23 ` Vaidyanathan Srinivasan
2007-01-25 11:57 ` Al Boldi
2007-01-25 11:57 ` Al Boldi
2007-01-25 18:37 ` Vaidyanathan Srinivasan
[not found] <7GEEK-4lH-39@gated-at.bofh.it>
[not found] ` <7GLdb-5Uz-13@gated-at.bofh.it>
[not found] ` <7GRix-7fU-1@gated-at.bofh.it>
[not found] ` <7GRLZ-7Uy-29@gated-at.bofh.it>
2007-01-25 14:51 ` Bodo Eggert
-- strict thread matches above, loose matches on Subject: below --
2007-01-24 0:49 Christoph Lameter
2007-01-24 2:53 ` KAMEZAWA Hiroyuki
2007-01-24 3:01 ` Christoph Lameter
2007-01-24 5:47 ` Aubrey Li
2007-01-24 3:00 ` Nick Piggin
2007-01-24 3:14 ` Christoph Lameter
2007-01-24 3:51 ` Aubrey Li
2007-01-24 4:03 ` Nick Piggin
2007-01-26 10:27 ` Andrew Morton
2007-01-24 3:13 ` KAMEZAWA Hiroyuki
2007-01-24 4:30 ` Christoph Lameter
2007-01-24 5:15 ` KAMEZAWA Hiroyuki
2007-01-25 0:32 ` KAMEZAWA Hiroyuki
2007-01-25 2:41 ` Christoph Lameter
2007-01-25 3:12 ` KAMEZAWA Hiroyuki
2007-01-25 4:28 ` Rik van Riel
2007-01-25 5:19 ` KAMEZAWA Hiroyuki
2007-01-25 5:40 ` Rik van Riel
2007-01-25 6:00 ` KAMEZAWA Hiroyuki
2007-01-26 10:29 ` Andrew Morton
2007-01-26 18:01 ` KAMEZAWA Hiroyuki
2007-01-24 7:04 ` Vaidyanathan Srinivasan
2007-01-24 7:55 ` Peter Zijlstra
2007-01-24 12:50 ` Nick Piggin
2007-01-24 12:58 ` Peter Zijlstra
2007-01-24 14:58 ` Christoph Lameter
2007-01-24 20:06 ` Erik Andersen
2007-01-25 2:40 ` Christoph Lameter
2007-01-25 8:07 ` Vaidyanathan Srinivasan
2007-01-24 14:22 ` Aubrey Li
2007-01-24 14:56 ` Peter Zijlstra
2007-01-25 2:27 ` Aubrey Li
2007-01-24 12:33 ` Vaidyanathan Srinivasan
2007-01-24 14:56 ` Christoph Lameter
2007-01-25 4:17 ` Vaidyanathan Srinivasan
2007-01-25 4:45 ` Rik van Riel
2007-01-25 5:49 ` Vaidyanathan Srinivasan
2007-01-25 16:07 ` Rik van Riel
2007-01-25 17:57 ` Balbir Singh
2007-01-25 6:35 ` Aubrey Li
2007-01-25 6:47 ` Christoph Lameter
2007-01-25 7:49 ` Vaidyanathan Srinivasan
2007-01-25 4:18 ` Rik van Riel
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=1169720945.6189.52.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=a1426z@gawab.com \
--cc=linux-kernel@vger.kernel.org \
--cc=svaidy@linux.vnet.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox