lkml.org 
[lkml]   [2005]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH/RFC] A method for clearing out page cache
Ingo Molnar wrote:
> * Andrew Morton <akpm@osdl.org> 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@vger.kernel.org
> 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@sgi.com raybry@austin.rr.com
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:10    [W:5.483 / U:0.576 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site