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.