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?
