From: Frederic Weisbecker <frederic@kernel.org>
To: Xi Wang <xii@google.com>
Cc: "Tejun Heo" <tj@kernel.org>,
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>,
"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: Wed, 7 May 2025 16:11:03 +0200 [thread overview]
Message-ID: <aBtp98E9q37FLeMv@localhost.localdomain> (raw)
In-Reply-To: <CAOBoifh4BY1f4B3EfDvqWCxNSV8zwmJPNoR3bLOA7YO11uGBCQ@mail.gmail.com>
Le Tue, May 06, 2025 at 08:43:57PM -0700, Xi Wang a écrit :
> On Tue, May 6, 2025 at 5:17 PM Tejun Heo <tj@kernel.org> wrote:
> For the use cases, there are two major requirements at the moment:
>
> Dynamic cpu affinity based isolation: CPUs running latency sensitive threads
> (vcpu threads) can change over time. We'd like to configure kernel thread
> affinity at run time too.
I would expect such latency sensitive application to run on isolated
partitions. And those already don't pull unbound kthreads.
> Changing cpu affinity at run time requires cpumask
> calculations and thread migrations. Sharing cpuset code would be nice.
There is already some (recent) affinity management in the kthread subsystem.
A list of kthreads having a preferred affinity (but !PF_NO_SETAFFINITY)
is maintained and automatically handled against hotplug events and housekeeping
state.
>
> Support numa based memory daemon affinity: We'd like to restrict kernel memory
> daemons but maintain their numa affinity at the same time. cgroup hierarchies
> can be helpful, e.g. create kernel, kernel/node0 and kernel/node1 and move the
> daemons to the right cgroup.
The kthread subsystem also handles node affinity. See kswapd / kcompactd. And it
takes care of that while still honouring isolated / isolcpus partitions:
d1a89197589c ("kthread: Default affine kthread to its preferred NUMA node")
>
> Workqueue coverage is optional. kworker threads can use their separate
> mechanisms too.
>
> Since the goal is isolation, we'd like to restrict as many kthreads as possible,
> even the ones that don't directly interact with user applications.
>
> The kthreadd case is handled - a new kthread can be forked inside a non root
> cgroup, but based on flags it can move itself to the root cgroup before threadfn
> is called.
kthreadd and other kthreads that don't have a preferred affinity are also
affine outside isolcpus/nohz_full. And since isolated cpuset partitions
create NULL domains, those kthreads won't run there either.
What am I missing?
Thanks.
--
Frederic Weisbecker
SUSE Labs
next prev parent reply other threads:[~2025-05-07 14:11 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
2025-05-07 3:43 ` Xi Wang
2025-05-07 14:11 ` Frederic Weisbecker [this message]
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=aBtp98E9q37FLeMv@localhost.localdomain \
--to=frederic@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=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=tj@kernel.org \
--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.