Re: userspace pagecache management tool

[bert hubert <bert.hubert@netherlabs.nl>]

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