Re: [PATCH 3/5] cpuset: change marker for relative numbering

[Paul Jackson <pj@sgi.com>]

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/