Re: [PATCH/RFC] A method for clearing out page cache

[Ray Bryant]

Ingo Molnar wrote:
> * Andrew Morton <akpm@xxxxxxxx> wrote:
>
>
> > > . enable users to
> > > specify an 'allocation priority' of some sort, which kicks out the
> > > pagecache on the local node - or something like that.
> >
> > Yes, that would be preferable - I don't know what the difficulty is
> > with that.  sys_set_mempolicy() should provide a sufficiently good
> > hint.
>
>
> yes. I'm not against some flushing mechanism for debugging or test
> purposes (it can be useful to start from a new, clean state - and as
> such the sysctl for root only and depending on KERNEL_DEBUG is probably
> better than an explicit syscall), but the idea to give a flushing API to
> applications is bad i believe.

We're pretty agnostic about this.  I agree that if we were to make this
a system call, then it should be restricted to root.  Or make it a
sysctl.  Whichever way you guys want to go is fine with us.

> It is the 'easy and incorrect path' to a number of NUMA (and non-NUMA)
> VM problems and i fear that it will destroy the evolution of VM
> priority/placement/affinity APIs (NUMAlib, etc.).

I have two observations about this:

(1)  It is our intent to use the infrastructure provided by this patch
     as the basis for an automatic (i. e. included with the VM) approach
     that selectively removes unused page cache pages before spilling
     off node.  We just figured it would be easier to get the
     infrastructure in place first.

(2)  If a sufficiently well behaved application knows in advance how
     much free memory it needs per node, then it makes sense to provide
     a mechanism for the application to request this, rather than for
     the VM to try to puzzle this out later.  Automatic algorithms in
     the VM are never perfect; they should be reserved to work in those
     cases where the application(s) either cooperate in such a way to
     make memory demands impossible to predict, or the application
     programmer can't (or can't take the time to) predict how much
     memory the application will use.

> At least making it sufficiently painful to use (via the originally
> proposed root-only sysctl) could still preserve some of the incentive to
> provide a clean solution for applications. 'Time to market' constraints
> should not be considered when adding core mechanisms.
>
> 	Ingo
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


--
Best Regards,
Ray
-----------------------------------------------
                  Ray Bryant
512-453-9679 (work)         512-507-7807 (cell)
raybry@xxxxxxx             raybry@xxxxxxxxxxxxx
The box said: "Requires Windows 98 or better",
           so I installed Linux.
-----------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/