Hi. I used top and htop programs to check what CPU is using, and it's showing that this task is running on CPU 2, so I think it shows the correct CPU that is currently being used. Please note that the containerd process has /system/runtime cgroup, which inherits cpuset from the root cgroup. /system/runtime cgroup doesn't have any cpuset settings. Maybe this is the reason? I tried to remove the lowlatency group with cpuset.cpus.partition=root and do taskset -cp 4 1079 manually, and it works without any restart. I updated my post on StackExchange and added some new screenshots, so please check it out. > On 29 Aug 2022, at 18:24, Waiman Long <longman@xxxxxxxxxx> wrote: > > On 8/23/22 12:23, Tejun Heo wrote: >> (cc'ing Waiman for visibilty) >> >> On Tue, Aug 23, 2022 at 03:13:30PM +0300, Maxim “MAXPAIN” Makarov wrote: >>> Hello. I have no idea where I can ask questions about cgroups v2. I have a problem with cpuset partitions. >>> Could you please, check this question? >>> https://unix.stackexchange.com/questions/714454/cgroups-v2-cpuset-doesnt-take-an-effect-without-process-restart > > When a partition is created, the cpuset code will update the cpu affinity of the tasks in the parent cpuset using update_tasks_cpumask(). This function will set the new cpu affinity for those tasks and move it over to the new cpus. However, if the tasks aren't running at the time, the move may be delayed until those tasks are waken up. The fact the task affinity is correct means that the cpuset code has done the right thing. > > I am not sure what tool do you use to check the task's cpus. I believe the tool may show what cpu the task is previously running on. It does not means the the task will run on that cpu when it is waken up. It is only a bug if the task is running and it is on the wrong cpu. > > Cheers, > Longman >
