From: Waiman Long <[email protected]>
To: Daniel Dao <[email protected]>, Jens Axboe <[email protected]>
Cc: [email protected], Tejun Heo <[email protected]>,
[email protected],
linux-kernel <[email protected]>,
kernel-team <[email protected]>
Subject: Re: Unexpected EINVAL when enabling cpuset in subtree_control when io_uring threads are running
Date: Wed, 8 Mar 2023 09:20:09 -0500 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+wXwBQwgxB3_UphSny-yAP5b26meeOu1W4TwYVcD_+5gOhvPw@mail.gmail.com>
On 3/8/23 06:42, Daniel Dao wrote:
> Hi all,
>
> We encountered EINVAL when enabling cpuset in cgroupv2 when io_uring
> worker threads are running. Here are the steps to reproduce the failure
> on kernel 6.1.14:
>
> 1. Remove cpuset from subtree_control
>
> > for d in $(find /sys/fs/cgroup/ -maxdepth 1 -type d); do echo
> '-cpuset' | sudo tee -a $d/cgroup.subtree_control; done
> > cat /sys/fs/cgroup/cgroup.subtree_control
> cpu io memory pids
>
> 2. Run any applications that utilize the uring worker thread pool. I used
> https://github.com/cloudflare/cloudflare-blog/tree/master/2022-02-io_uring-worker-pool
>
> > cargo run -- -a -w 2 -t 2
>
> 3. Enabling cpuset will return EINVAL
>
> > echo '+cpuset' | sudo tee -a /sys/fs/cgroup/cgroup.subtree_control
> +cpuset
> tee: /sys/fs/cgroup/cgroup.subtree_control: Invalid argument
>
> We traced this down to task_can_attach that will return EINVAL when it
> encounters
> kthreads with PF_NO_SETAFFINITY, which io_uring worker threads have.
>
> This seems like an unexpected interaction when enabling cpuset for the subtrees
> that contain kthreads. We are currently considering a workaround to try to
> enable cpuset in root subtree_control before any io_uring applications
> can start,
> hence failure to enable cpuset is localized to only cgroup with
> io_uring kthreads.
> But this is cumbersome.
>
> Any suggestions would be very much appreciated.
Anytime you echo "+cpuset" to cgroup.subtree_control to enable cpuset,
the tasks within the child cgroups will do an implicit move from the
parent cpuset to the child cpusets. However, that move will fail if any
task has the PF_NO_SETAFFINITY flag set due to task_can_attach()
function which checks for this. One possible solution is for the cpuset
to ignore tasks with PF_NO_SETAFFINITY set for implicit move. IOW,
allowing the implicit move without touching it, but not explicit one
using cgroup.procs.
Cheers,
Longman
next prev parent reply other threads:[~2023-03-08 14:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-08 11:42 Unexpected EINVAL when enabling cpuset in subtree_control when io_uring threads are running Daniel Dao
2023-03-08 13:50 ` Jens Axboe
2023-03-08 14:20 ` Waiman Long [this message]
2023-03-08 14:26 ` Jens Axboe
2023-03-08 14:44 ` Waiman Long
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 \
[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