[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070303230155.GA475@outpost.ds9a.nl>
Date: Sun, 4 Mar 2007 00:01:55 +0100
From: bert hubert <bert.hubert@...herlabs.nl>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Rik van Riel <riel@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: userspace pagecache management tool
On Sat, Mar 03, 2007 at 02:26:09PM -0800, Andrew Morton wrote:
> > > It is *not* a global instruction. It uses setenv, so the user's policy
> > > affects only the target process and its forked children.
> >
> > ... and all other processes accessing the same file(s)!
> >
> > Your library and the system calls may be limited to one process,
> > but the consequences are global.
>
> Yes. So what? If the user wants to go and evict libc.so from pagecache
> then he can do so - the kernel has provided syscalls with which this can be
> done for at least seven years. Bad user, shouldn't do that.
While I agree with your sentiments that userspace can have a good idea on
how to deal with the page cache, your program does more than it claims to
do - because of how linux implements posix_fadvise.
I don't think anybody expects or desires your program to actually *evict*
the stuff from the cache you are trying access, which happens in case the
data was in the cache prior to starting your program.
What people expect is that a solution such as you wrote it simply won't
*add* anything to the cache. They don't expect it will actually globally
*remove* stuff from the cache.
Making a backup this way would hurt even worse than usual with your
pagecache management tool if the file being backupped was still being read.
This is not your fault, but in practice, it makes your program less useful
than it could be.
One could conceivably fix that up using mincore and simply not fadvise if a
page was in core already.
Bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists