From: Tejun Heo <tj@kernel.org>
To: Xi Wang <xii@google.com>
Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
"Ingo Molnar" <mingo@redhat.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Juri Lelli" <juri.lelli@redhat.com>,
"Vincent Guittot" <vincent.guittot@linaro.org>,
"Dietmar Eggemann" <dietmar.eggemann@arm.com>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Ben Segall" <bsegall@google.com>,
"David Rientjes" <rientjes@google.com>,
"Mel Gorman" <mgorman@suse.de>,
"Valentin Schneider" <vschneid@redhat.com>,
"Waiman Long" <longman@redhat.com>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Michal Koutný" <mkoutny@suse.com>,
"Lai Jiangshan" <jiangshanlai@gmail.com1>,
"Frederic Weisbecker" <frederic@kernel.org>,
"Vlastimil Babka" <vbabka@suse.cz>,
"Dan Carpenter" <dan.carpenter@linaro.org>,
"Chen Yu" <yu.c.chen@intel.com>, "Kees Cook" <kees@kernel.org>,
"Yu-Chun Lin" <eleanor15x@gmail.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Mickaël Salaün" <mic@digikod.net>
Subject: Re: [RFC/PATCH] sched: Support moving kthreads into cpuset cgroups
Date: Tue, 6 May 2025 14:17:30 -1000 [thread overview]
Message-ID: <aBqmmtST-_9oM9rF@slm.duckdns.org> (raw)
In-Reply-To: <20250506183533.1917459-1-xii@google.com>
Hello,
On Tue, May 06, 2025 at 11:35:32AM -0700, Xi Wang wrote:
> In theory we should be able to manage kernel tasks with cpuset
> cgroups just like user tasks, would be a flexible way to limit
> interferences to real-time and other sensitive workloads. This is
> however not supported today: When setting cpu affinity for kthreads,
> kernel code uses a simpler control path that directly lead to
> __set_cpus_allowed_ptr or __ktread_bind_mask. Neither honors cpuset
> restrictions.
>
> This patch adds cpuset support for kernel tasks by merging userspace
> and kernel cpu affinity control paths and applying the same
> restrictions to kthreads.
>
> The PF_NO_SETAFFINITY flag is still supported for tasks that have to
> run with certain cpu affinities. Kernel ensures kthreads with this
> flag have their affinities locked and they stay in the root cpuset:
>
> If userspace moves kthreadd out of the root cpuset (see example
> below), a newly forked kthread will be in a non root cgroup as well.
> If PF_NO_SETAFFINITY is detected for the kthread, it will move itself
> into the root cpuset before the threadfn is called. This does depend
> on the kthread create -> kthread bind -> wake up sequence.
Can you describe the use cases in detail? This is not in line with the
overall direction. e.g. We're making cpuset work with housekeeping mechanism
and tell workqueue which CPUs can be used for unbound execution and kthreads
which are closely tied to userspace activities are spawned into the same
cgroups as the user thread and subject to usual resource control.
There are a lot of risks in subjecting arbitrary kthreads to all cgroup
resource controls and just allowing cpuset doesn't seem like a great idea.
Integration through housekeeping makes a lot more sense to me. Note that
even for just cpuset thread level control doesn't really work that well. All
kthreads are forked by kthreadd. If you move the kthreadd into a cgroup, all
kthreads includling kworkers for all workqueues will be spawned there. The
granularity of control isn't much better than going through housekeeping.
Thanks.
--
tejun
next prev parent reply other threads:[~2025-05-07 0:17 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-06 18:35 [RFC/PATCH] sched: Support moving kthreads into cpuset cgroups Xi Wang
2025-05-06 19:57 ` Waiman Long
2025-05-06 23:15 ` Xi Wang
2025-05-07 0:17 ` Tejun Heo [this message]
2025-05-07 3:43 ` Xi Wang
2025-05-07 14:11 ` Frederic Weisbecker
2025-05-07 17:23 ` Xi Wang
2025-05-07 17:36 ` Tejun Heo
2025-05-07 20:07 ` Xi Wang
2025-05-08 0:08 ` Frederic Weisbecker
2025-05-08 17:51 ` Xi Wang
2025-05-08 19:34 ` Waiman Long
2025-05-08 22:39 ` Xi Wang
2025-05-09 0:30 ` Waiman Long
2025-05-09 16:52 ` Xi Wang
2025-05-12 10:36 ` Michal Koutný
2025-05-12 18:55 ` Xi Wang
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=aBqmmtST-_9oM9rF@slm.duckdns.org \
--to=tj@kernel.org \
--cc=bsegall@google.com \
--cc=cgroups@vger.kernel.org \
--cc=dan.carpenter@linaro.org \
--cc=dietmar.eggemann@arm.com \
--cc=eleanor15x@gmail.com \
--cc=frederic@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=jiangshanlai@gmail.com1 \
--cc=juri.lelli@redhat.com \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mgorman@suse.de \
--cc=mic@digikod.net \
--cc=mingo@redhat.com \
--cc=mkoutny@suse.com \
--cc=peterz@infradead.org \
--cc=rientjes@google.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=vbabka@suse.cz \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=xii@google.com \
--cc=yu.c.chen@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.