Hi, Ridong,
On Thu, 27 Nov 2025 09:55:21, Chen Ridong wrote:
I have to admit that I prefer the current implementation.
At the very least, it ensures that all partitions are treated fairly[1]. Relaxing this rule would make it more difficult for users to understand why the cpuset.cpus they configured do not match the effective CPUs in use, and why different operation orders yield different results.
As for "different operation orders yield different results", Below is an example that is not a corner case.
root cgroup / \ A1 B1
#1> echo "0" > A1/cpuset.cpus #2> echo "0-1" > B1/cpuset.cpus.exclusive --> return error
#1> echo "0-1" > B1/cpuset.cpus.exclusive #2> echo "0" > A1/cpuset.cpus
In another scenario, if we do not invalidate the siblings, new leaf cpusets (marked as member) created under A1 will end up with empty effective CPUs—and this is not a desired behavior.
root cgroup | A1 / \ A2 A3...
#1> echo "0-1" > A1/cpuset.cpus #2> echo "root" > A1/cpuset.cpus.partition #3> echo "0-1" > A2/cpuset.cpus #4> echo "root" > A2/cpuset.cpus.partition mkdir A4 mkdir A5 echo "0" > A4/cpuset.cpus echo $$ > A4/cgroup.procs echo "1" > A5/cpuset.cpus echo $$ > A5/cgroup.procs
If A2...A5 all belong to the same user, and that user wants both A4 and A5 to have effective CPUs, then the user should also understand that A2 needs to be adjusted to "member" instead of "root".
if A2...A5 belong to different users, must satisfying user A4’s requirement come at the expense of user A2’s requirement? That is not fair.
[1]: "B1 is a second-class partition only because it starts later or why is it OK to not fulfill its requirement?" --Michal.
Thanks, Sun Shaojie