LKML Archive on
help / color / mirror / Atom feed
From: Nick Piggin <>
To: Aubrey Li <>
Cc: Vaidyanathan Srinivasan <>,,,
	Linus Torvalds <>, Andrew Morton <>,
	"linux-os (Dick Johnson)" <>,
	Robin Getz <>,
	"Hennerich, Michael" <>
Subject: Re: [RPC][PATCH 2.6.20-rc5] limit total vfs page cache
Date: Sat, 20 Jan 2007 13:24:45 +1100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Aubrey Li wrote:
> On 1/20/07, Vaidyanathan Srinivasan <> wrote:

>> If pagecache is overlimit, we expect old (cold) pagecache pages to
>> be thrown out and reused for new file data.  We do not expect to
>> drop a few text or data pages to make room for new pagecache.
> Well, actually I think this probably not necessary. Because the
> reclaimer has no way to predict the behavior of user mode processes,
> how do you make sure the pagecache will not be access again in a short

It is not about predicting behaviour, it is about directing the reclaim
effort at the actual resource that is under pressure.

Even given a pagecache limiting patch which does the proper accounting
to keep pagecache pages under a % limit (unlike yours), kicking off an
undirected reclaim could (in theory) reclaim all slab and anonymous
memory pages before bringing pagecache under the limit. So I think
you need to be a bit more thorough than just assuming everything will
be OK. Page reclaim behaviour is pretty strange and complex.

Secondly, your patch isn't actually very good. It unconditionally
shrinks memory to below the given % mark each time a pagecache alloc
occurs, regardless of how much pagecache is in the system. Effectively
that seems to just reduce the amount of memory available to the system.

Luckily, there are actually good, robust solutions for your higher
order allocation problem. Do higher order allocations at boot time,
modifiy userspace applications, or set up otherwise-unused, or easily
reclaimable reserve pools for higher order allocations. I don't
understand why you are so resistant to all of these approaches?

SUSE Labs, Novell Inc.
Send instant messages to your online friends 

  reply	other threads:[~2007-01-20  2:25 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-18  3:23 Aubrey Li
2007-01-19 14:44 ` Vaidyanathan Srinivasan
2007-01-19 15:40   ` Aubrey Li
2007-01-24  5:30     ` Vaidyanathan Srinivasan
2007-01-24  5:53       ` Aubrey Li
2007-01-19 14:52 ` Vaidyanathan Srinivasan
2007-01-19 16:05   ` Aubrey Li
2007-01-19 18:49     ` Vaidyanathan Srinivasan
2007-01-19 19:01       ` Christoph Lameter
2007-01-20  2:04       ` Aubrey Li
2007-01-20  2:24         ` Nick Piggin [this message]
2007-01-20  2:35           ` Mike Frysinger
2007-01-20  2:49             ` Nick Piggin
2007-01-20  3:40               ` Mike Frysinger
2007-01-20  3:08           ` Aubrey Li
2007-01-20  4:03             ` Nick Piggin
2007-01-20  4:26               ` Aubrey Li
2007-01-22 19:22                 ` Christoph Lameter
2007-01-22 19:15               ` Christoph Lameter
2007-01-19 18:21 ` Christoph Lameter

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 \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [RPC][PATCH 2.6.20-rc5] limit total vfs page cache' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).