Andrew wrote:
> Paul, could you please describe what cpusets' policy is in the presence of
> CPU additional and removal?
Currently, if we remove the last CPU in a cpuset, we give that cpuset
the CPUs of its parent cpuset, in order to ensure that every cpuset
with tasks attached actually has some CPUs they can run on. See the
routine kernel/cpuset.c:guarantee_online_cpus_mems_in_subtree(), and
kernel/cpuset.c:guarantee_online_cpus(), and close your eyes to the
recursion ... yeah that has to get fixed someday ;).
But Cliff Wickman <[EMAIL PROTECTED]> (added to CC) figured out that this was
broken, as it could easily violate the cpu_exclusive property of
cpusets. He is working on a patch that will move the tasks in the
CPU-deficient cpuset up to their parent cpuset.
In general, the idea is to ensure that every task has at least one CPU
on which it can run. If the sysadmin intends to unplug all the CPUs
required by some task, he "should" first move those tasks somewhere
else where they can continue to run. If he doesn't, then the kernel
"makes do", by either (currently) adding CPUs to the CPU-deficient
cpuset, or (future) moving the CPU-deprived tasks somewhere else.
--
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/
