From: Andrew Morton <akpm@linux-foundation.org>
To: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Cc: bert.hubert@netherlabs.nl, riel@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: userspace pagecache management tool
Date: Thu, 8 Mar 2007 00:12:35 -0800 [thread overview]
Message-ID: <20070308001235.d7cb099e.akpm@linux-foundation.org> (raw)
In-Reply-To: <45EFC246.4050807@linux.vnet.ibm.com>
> On Thu, 08 Mar 2007 13:29:02 +0530 Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> wrote:
> > That all sounds reasonably doable. It'd be pretty complex to do it
> > in-kernel but we could do it there too. Problem is if course that the
> > above strategy is explicitly optimised for the backup program and if it's
> > in-kernel it becomes applicable to all other workloads.
>
> This strategy looks very good. However we are not considering the
> performance impact on the 'backup' application as such. By removing
> pagecache pages brought in by the application without the knowledge of
> the applications usage and behavior may severely affect its performance.
>
> Certainly we are interested in improving system performance at the
> cost certain applications, but not to an extend that the backup
> process will drag on and on to an unreasonable amount of time.
>
> Also backup processes may consist of a group of applications working
> on the same stream of data. Like compression program, encryption
> program etc which could be independent applications.
Well yes, if the application is that funky then suitably funky userspace
tricks will be needed to avoid hurting it.
> We should consider having a limit on pagecache usage rather than
> denying any space in the pagecache for these applications.
That's what containerisation is for:
run-in-container --memory=16M /bin/backup-program
This can be done today with x86_64 fake-numa, controlled by cpusets. One
day, when we get our containerisation story sorted out, things will be more
convenient...
> Can fadvice() be enhanced to have a limit on pagecache usage and
> reclaim used pages in LRU order? This way data stays for a little
> while for other applications to pickup from pagecache.
>
> Pages already in memory or brought in by other applications need not
> be placed in this list and hence we prevent any collateral pageouts.
We could teach the presently-unimplemented POSIX_FADV_NOREUSE to dump this
file's pages at the tail of the inactive list (after cleaning them if
needed). That way, they're the first to get reclaimed.
The standard says "Specifies that the application expects to access the
specified data once and then not reuse it thereafter." That's a bit
ambiguous: it it before the process accessed the data, or after? Before, I
suspect.
next prev parent reply other threads:[~2007-03-08 8:12 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-03 20:29 userspace pagecache management tool Andrew Morton
2007-03-03 20:40 ` Rik van Riel
2007-03-03 21:12 ` Andrew Morton
2007-03-03 21:30 ` Rik van Riel
2007-03-03 21:41 ` bert hubert
2007-03-03 22:14 ` Andrew Morton
2007-03-03 22:19 ` Rik van Riel
2007-03-03 22:26 ` Andrew Morton
2007-03-03 22:28 ` Rik van Riel
2007-03-03 22:38 ` Andrew Morton
2007-03-03 22:56 ` Erik Andersen
2007-03-03 23:01 ` bert hubert
2007-03-03 23:45 ` Andrew Morton
2007-03-06 12:10 ` Pádraig Brady
2007-03-06 21:40 ` Andrew Morton
2007-03-06 21:44 ` Rik van Riel
2007-03-07 11:39 ` Pádraig Brady
2007-03-07 18:50 ` Andrew Morton
2007-03-08 7:59 ` Vaidyanathan Srinivasan
2007-03-08 8:12 ` Andrew Morton [this message]
2007-03-03 22:07 ` Andrew Morton
2007-03-03 22:25 ` Rik van Riel
2007-03-03 22:37 ` Andrew Morton
2007-03-03 22:52 ` Andrew Morton
2007-03-04 0:01 ` Rik van Riel
2007-03-04 1:02 ` Andrew Morton
2007-03-04 1:23 ` Rik van Riel
2007-03-04 1:49 ` Andrew Morton
2007-03-04 1:56 ` Rik van Riel
2007-03-04 12:07 ` Andrew Morton
2007-03-04 14:35 ` Peter Zijlstra
2007-03-04 16:01 ` Rik van Riel
2007-03-03 22:58 ` Ray Lee
2007-03-03 23:34 ` Andrew Morton
2007-03-04 1:02 ` Ray Lee
2007-03-04 1:21 ` Andrew Morton
2007-03-04 0:14 ` Eric St-Laurent
2007-03-04 1:10 ` Andrew Morton
2007-03-04 1:39 ` Rik van Riel
2007-03-04 1:16 ` Lee Revell
2007-03-04 1:39 ` Andrew Morton
2007-03-04 2:35 ` Lee Revell
2007-03-04 4:35 ` Andrew Morton
2007-03-05 11:02 ` Pádraig Brady
2007-03-05 11:12 ` Andrew Morton
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=20070308001235.d7cb099e.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=bert.hubert@netherlabs.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@redhat.com \
--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