Messages in this thread | | | Date | Sun, 6 Nov 2005 14:49:54 -0800 | From | Paul Jackson <> | Subject | Re: [PATCH 3/5] cpuset: change marker for relative numbering |
| |
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 <pj@sgi.com> 1.925.600.0401 - 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/
| |