public inbox for [email protected]
 help / color / mirror / Atom feed
From: "MOESSBAUER, Felix" <[email protected]>
To: "[email protected]" <[email protected]>,
	"[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>,
	"[email protected]" <[email protected]>,
	"Bezdeka, Florian" <[email protected]>,
	"[email protected]" <[email protected]>,
	"[email protected]" <[email protected]>,
	"[email protected]" <[email protected]>,
	"Schmidt, Adriaan" <[email protected]>,
	"[email protected]" <[email protected]>
Subject: Re: [PATCH 1/1] io_uring/sqpoll: inherit cpumask of creating process
Date: Fri, 6 Sep 2024 13:52:32 +0000	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

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



  reply	other threads:[~2024-09-06 13:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-06 13:44 [PATCH 1/1] io_uring/sqpoll: inherit cpumask of creating process Felix Moessbauer
2024-09-06 13:47 ` Jens Axboe
2024-09-06 13:52   ` MOESSBAUER, Felix [this message]
2024-09-06 13:55     ` Jens Axboe
2024-09-06 13:54 ` Jens Axboe
2024-09-06 16:00 ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=236f0c6d019e8c25301f3db0a5c9d4971a094eb9.camel@siemens.com \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox