Andrew wrote:
> If someone modifies a library-managed cpuset via the backdoor then the
> library (and its caller) are out of sync with reality _anyway_.
Yes, for system-wide operations. No - for cpuset-relative operations.
For task migration (Christoph Lameter's patches) to work, I need to
provide a safe way for jobs to manage placement within their assigned
cpuset. This means providing wrappers to sched_setaffinity, mbind and
set_mempolicy that take cpuset-relative cpu/mem numbers, and provide a
robust, cpuset-relative API to applications, that hides any migrations
from the application.
A year ago, Simon Derr pushed hard to get cpuset-relative numbering
support into the kernel, anticipating these sorts of problems. I and
others pushed back, saying that this was the work of libraries, and
that the kernel-user API needed to use one simple, system-wide numbering.
Enforcing a system-wide synchronization of library code, using just
user code, is expensive, difficult and scales poorly on large systems.
A trivial, code-wise, hook in the kernel will enable each independent
library routine to efficiently detect any parallel changes and redo
their operation sequence. It enables providing applications with a
cpuset-relative API for internal job memory and cpu placement that is
efficient and robustly safe in the face of migrations.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.925.600.0401
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
