Hello.
On Mon, Dec 01, 2025 at 05:44:47PM +0800, Sun Shaojie sunshaojie@kylinos.cn wrote:
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
Here it is a combination of remote cs local partitions. I'd like to treat the two approaches separately and better not consider their combination.
The idea (and permissions check AFACS) behind remote partitions is to allow "stealing" CPU ownership so cpuset.cpus.exclusive has different behavior.
root cgroup | A1 //MK: A4 A5 here? / \ A2 A3... //MK: A4 A5 or here?
#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.
If A4 is a sibling at the level of A1, then A2 must be stripped of its CPUs to honor the hierarchy hence the apparent unfairness.
If A4 is a sibling at the level of A2 and they have different owning users, their respective cpuset.cpus should only be writable by A1's user (the one who distributes the cpus) so that any arbitration between the siblings is avoided.
0.02€, Michal