On 2022-11-11 11:37:03 [-0500], Waiman Long wrote: > > On 11/11/22 10:34, Sebastian Andrzej Siewior wrote: > > On 2022-11-02 09:20:48 [-0400], Waiman Long wrote: > > Hi, > > > > > Yes, that is a known issue which is especially problematic when cgroup v2 is > > > used. That is why I have recently posted a set of patches to enable > > > persistent user requested affinity and they have been merged into tip: > > > > > > 851a723e45d1 sched: Always clear user_cpus_ptr in do_set_cpus_allowed() > > > da019032819a sched: Enforce user requested affinity > > > 8f9ea86fdf99 sched: Always preserve the user requested cpumask > > > 713a2e21a513 sched: Introduce affinity_context > > > 5584e8ac2c68 sched: Add __releases annotations to affine_move_task() > > > They should be able to address the problem that you list here. Please let me > > > know if there are still problem remaining. > > Thank you. This solves the most pressing issue. The CPU-mask is still > > reset upon activation of the cpuset controller. > > This is due to the set_cpus_allowed_ptr() in cpuset_attach(). > > > > Is is possible to push these patches stable? > > Actually, I prefer to not call set_cpus_allowed_ptr() if the cpumask of the > old and new cpusets are the same. That will save some cpu cycles. Similarly > for node_mask. If there is any changes in the cpumask, we have to call > set_cpus_allowed_ptr(). I will work out a patch to that effect when I have > spare cycle. But couldn't we skip that set_cpus_allowed_ptr() if the current mask is a subset of the new mask and keep the behavior that the mask isn't changed if the cgroup's mask changes but is still a subset? That cpuset_attach() callback is only invoked while the task is initially added to the cgroup which happens during enabling of the controller. Or do I miss another common usecase? > Thanks, > Longman Sebastian
