Re: [PATCH 1/1] io_uring/sqpoll: inherit cpumask of creating process

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux