Hi, Ridong On Sat, 13 Dec 2025 08:52:11 +0800, Chen Ridong wrote: >On 2025/12/1 17:44, Sun Shaojie wrote: >> 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 >> > >You're looking at one rule, but there's another one—Longman pointed out that >setting cpuset.cpu >should never fail.
Precisely because I know that setting cpuset.cpus should never fail, I provided this example, which is why it demonstrates that "different operation orders yield different results." >>> >>> 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. >> > >Regarding cpuset usage with Docker: when binding CPUs at container startup, do >you check the sibling >CPUs in use? Without this check, A2 will not be invalidated. > >Your patch has been discussed for a while. It seems to make the rules more >complex. My aim is to safeguard the independence of sibling nodes while adhering to existing rules. I continuously update the patch to uphold these rules, as seen in the recently updated patch v6 (https://lore.kernel.org/cgroups/[email protected]/). Thanks, Sun Shaojie
