On 11/2/22 06:55, Sebastian Andrzej Siewior wrote:
Hi,
while playing with cgroups and tasks which alter their CPU-mask I
noticed a behaviour which is unwanted:
- Upon enabling the cpuset controller, all currently set CPU-mask are
changed. Here one could argue how bad it is assuming that the
controller gets only enabled once during boot.
- While having a task limited to only one CPU (or more but a subset of
the cpuset's mask) then adding an additional CPU (or removing an
unrelated CPU) from that cpuset results in changing the CPU-mask of
that task and adding additional CPUs.
The test used to verify the behaviour:
# Limit to CPU 0-1
$ taskset -pc 0-1 $$
# Enable the cpuset controller
$ echo "+cpu" >> /sys/fs/cgroup/cgroup.subtree_control ; echo "+cpuset" >> /sys/fs/cgroup/cgroup.subtree_control
# Query the CPU-mask. Expect to see 0-1 since it is a subset of
# all-online-CPUs
$ taskset -pc $$
# Update the mask to CPUs 1-2
$ taskset -pc 1-2 $$
# Change the CPU-mask of the cgroup to CPUs 1-3.
$ echo 1-3 > /sys/fs/cgroup/user.slice/cpuset.cpus
# Expect to see 1-2 because it is a subset of 1-3
$ taskset -pc $$
# Change the CPU-mask of the cgroup to CPUs 2-3.
$ echo 2-3 > /sys/fs/cgroup/user.slice/cpuset.cpus
# Expect to see 2-3 because CPU 1 is not part of 2-3
$ taskset -pc $$
# Change the CPU-mask of the cgroup to CPUs 2-4.
$ echo 2-4 > /sys/fs/cgroup/user.slice/cpuset.cpus
# Expect to see 2-4 because task's old CPU-mask matches the old mask of
# the cpuset.
$ taskset -pc $$
Posting this as RFC in case I'm missing something obvious or breaking an
unknown (to me) requirement that this series would break.
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.
Thanks,
Longman
