Ingo Molnar wrote:
* Andrew Morton <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
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)
[EMAIL PROTECTED] [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
