On 7/28/22 12:50, Valentin Schneider wrote:
On 28/07/22 10:59, Waiman Long wrote:
On 7/28/22 10:44, Michal Koutný wrote:
This should apply only to tasks that were extracted out of the root
cgroup, no? (OK, those are all processes practically.)
The reset is done on all cgroups in a particular subtree. In the case of
cgroup root, it is all the processes in the system.
I've been briefly playing with this, tasks in the cgroup root don't seem
affected on my end (QEMU + buildroot + latest tip/sched/core):
$ mount -t cgroup2 none /sys/fs/cgroup
$ /root/loop.sh &
$ PID=$!
$ taskset -pc 2-3 $PID
pid 177's current affinity list: 0-3
pid 177's new affinity list: 2,3
$ echo +cpuset > /sys/fs/cgroup/cgroup.subtree_control
$ taskset -pc $PID
pid 177's current affinity list: 2,3
However tasks extracted out as mentioned by Michal definitely are:
$ mount -t cgroup2 none /sys/fs/cgroup
$ /root/loop.sh &
$ PID=$!
$ taskset -pc 2-3 $PID
pid 172's current affinity list: 0-3
pid 172's new affinity list: 2,3
$ mkdir /sys/fs/cgroup/foobar
$ echo $PID > /sys/fs/cgroup/foobar/cgroup.procs
$ taskset -pc $PID
pid 172's current affinity list: 2,3
$ echo +cpuset > /sys/fs/cgroup/cgroup.subtree_control
$ taskset -pc $PID
pid 172's current affinity list: 0-3
IIUC this is just what happens anytime a task gets migrated to a new
cpuset. Initially loop.sh remains attached to the root cpuset, and the echo
+cpuset migrates it to the /foobar one.
Does that match what you're seeing?
Yes. echo "+cpuset" to subtree_control means tasks in the child cgroups
will move to new cpusets. Those new cpusets will have the same cpu lists
as the parent unless the cpuset.cpus files are explicitly written to.
This patch will ensure that tasks that have explicitly set their cpu
affinity won't be affected by this change.
Cheers,
Longman
