On Fri, 2024-09-06 at 07:47 -0600, Jens Axboe wrote: > 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. One more reason to behave like a userland thread. I used the term "kernel" thread as it was used in commit a5fc1441af as well, referring to the same thing. Shall I update the commit message? Best regards, Felix > > > 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. > -- Siemens AG, Technology Linux Expert Center
