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
