On 11/11/22 11:49, Sebastian Andrzej Siewior wrote:
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?
The only way a userspace task can have a cpumask different from that of
its cpuset is by calling sched_setaffinity() which will be covered by
the persistent user requested mask change. So your patch 2 isn't really
needed.
Your patch 1 is relatively simple and I don't have a big objection to
that. I will let others chime in on what their thoughts are.
Cheers,
Longman
