From: Ingo Molnar <mingo@elte.hu>
To: Andrew Morton <akpm@osdl.org>
Cc: Ray Bryant <raybry@sgi.com>,
mort@wildopensource.com, pj@sgi.com,
linux-kernel@vger.kernel.org, hilgeman@sgi.com
Subject: Re: [PATCH/RFC] A method for clearing out page cache
Date: Tue, 22 Feb 2005 08:53:04 +0100 [thread overview]
Message-ID: <20050222075304.GA778@elte.hu> (raw)
In-Reply-To: <20050221144108.40eba4d9.akpm@osdl.org>
* Andrew Morton <akpm@osdl.org> wrote:
> > However, the first step is to do this manually from user space.
>
> Yup. The thing is, lots of people want this feature for various
> reasons. Not just numerical-computing-users-on-NUMA. We should get
> it right for them too.
>
> Especially kernel developers, who have various nasty userspace tools
> which will manually reclaim pagecache. But non-kernel-developers will
> use it too, when they think the VM is screwing them over ;)
app designers very frequently think that the VM gets its act wrong (most
of the time for the wrong reasons), and the last thing we want to enable
them is to hack real problems around. How are we supposed to debug VM
problems where one player periodically flushes the whole pagecache? If
that flushing, when disabled, 'results in the app being broken' (_if_
the app gives any option to disable the flushing). Providing APIs to
flush system caches, sysctl or syscall, is the road to VM madness.
If the goal is to override the pagecache (and other kernel caches) on a
given node then for God's sake, think a bit harder. E.g. enable users to
specify an 'allocation priority' of some sort, which kicks out the
pagecache on the local node - or something like that. Giving a
half-assed tool to clean out one aspect of the system caches will only
muddy the waters, with no real road back to sanity.
Ingo
next prev parent reply other threads:[~2005-02-22 7:53 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-14 15:44 [PATCH/RFC] A method for clearing out page cache Martin Hicks
2005-02-15 3:37 ` Paul Jackson
2005-02-16 19:56 ` Martin Hicks
2005-02-21 19:27 ` Martin Hicks
2005-02-21 21:42 ` Andrew Morton
2005-02-21 22:12 ` Paul Jackson
2005-02-21 22:28 ` Andrew Morton
2005-02-21 23:52 ` Paul Jackson
2005-02-21 22:28 ` Ray Bryant
2005-02-21 22:41 ` Andrew Morton
2005-02-21 23:01 ` Ray Bryant
2005-02-22 7:53 ` Ingo Molnar [this message]
2005-02-22 8:07 ` Andrew Morton
2005-02-22 8:24 ` Ingo Molnar
2005-02-22 17:29 ` Ray Bryant
2005-02-22 11:26 ` Paul Jackson
2005-02-22 18:45 ` Andrew Morton
2005-02-22 18:59 ` Martin Hicks
2005-02-22 19:03 ` Ray Bryant
2005-02-23 0:14 ` Paul Jackson
2005-03-01 21:54 ` Pavel Machek
2005-02-21 21:52 ` Nish Aravamudan
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=20050222075304.GA778@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@osdl.org \
--cc=hilgeman@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mort@wildopensource.com \
--cc=pj@sgi.com \
--cc=raybry@sgi.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