On 9/6/24 7:44 AM, Felix Moessbauer wrote: > The submit queue polling threads are "kernel" threads that are started It's not a kernel thread, it's a normal userland thread that just never exits to userspace. > from the userland. In case the userland task is part of a cgroup with > the cpuset controller enabled, the poller should also stay within that > cpuset. This also holds, as the poller belongs to the same cgroup as > the task that started it. > > With the current implementation, a process can "break out" of the > defined cpuset by creating sq pollers consuming CPU time on other CPUs, > which is especially problematic for realtime applications. > > Part of this problem was fixed in a5fc1441 by dropping the > PF_NO_SETAFFINITY flag, but this only becomes effective after the first > modification of the cpuset (i.e. the pollers cpuset is correct after the > first update of the enclosing cgroups cpuset). > > By inheriting the cpuset of the creating tasks, we ensure that the > poller is created with a cpumask that is a subset of the cgroups mask. > Inheriting the creators cpumask is reasonable, as other userland tasks > also inherit the mask. Looks fine to me. -- Jens Axboe
