linux-kernel - Re: [RFC/PATCH] sched: Support moving kthreads into cpuset cgroups

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAOBoifiYV3YX6nAf9v5PwkkKPt4qhV8af47mWoJQ1B_tFJ7D-g@mail.gmail.com>
Date: Mon, 12 May 2025 11:55:57 -0700
From: Xi Wang <xii@...gle.com>
To: Michal Koutný <mkoutny@...e.com>
Cc: linux-kernel@...r.kernel.org, cgroups@...r.kernel.org, 
	Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>, 
	Juri Lelli <juri.lelli@...hat.com>, Vincent Guittot <vincent.guittot@...aro.org>, 
	Dietmar Eggemann <dietmar.eggemann@....com>, Steven Rostedt <rostedt@...dmis.org>, 
	Ben Segall <bsegall@...gle.com>, David Rientjes <rientjes@...gle.com>, Mel Gorman <mgorman@...e.de>, 
	Valentin Schneider <vschneid@...hat.com>, Waiman Long <longman@...hat.com>, Tejun Heo <tj@...nel.org>, 
	Johannes Weiner <hannes@...xchg.org>, Lai Jiangshan <jiangshanlai@...il.com1>, 
	Frederic Weisbecker <frederic@...nel.org>, Vlastimil Babka <vbabka@...e.cz>, 
	Dan Carpenter <dan.carpenter@...aro.org>, Chen Yu <yu.c.chen@...el.com>, 
	Kees Cook <kees@...nel.org>, Yu-Chun Lin <eleanor15x@...il.com>, 
	Thomas Gleixner <tglx@...utronix.de>, Mickaël Salaün <mic@...ikod.net>
Subject: Re: [RFC/PATCH] sched: Support moving kthreads into cpuset cgroups

On Mon, May 12, 2025 at 3:36 AM Michal Koutný <mkoutny@...e.com> wrote:
>
> Hello.
>
> On Tue, May 06, 2025 at 11:35:32AM -0700, Xi Wang <xii@...gle.com> 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.
>
> I can see that this might be good for PF_USER_WORKER type of kernel
> tasks. However, generic kernel tasks are spawned by kernel who
> knows/demands which should run where and therefore they should not be
> subject to cpuset restrictions. When limiting interference is
> considered, there's CPU isolation for that.
>
> The migratable kthreadd seems too coarse grained approach to me (also
> when compared with CPU isolation).
> I'd mostly echo Tejun's comment [1].
>
> Regards,
> Michal
>
> [1] https://lore.kernel.org/r/aBqmmtST-_9oM9rF@slm.duckdns.org/

Kernel doesn't actually have the best information because it doesn't know which
user threads are more important. Giving the root user more power for fine tuning
is a common practice.

The most important reason for moving kthreadd is to prevent a kthread from
interfering with important user threads right after forking. It can still be
moved to other cgroups later. Moving kthreadd allows better control rather than
worse control.

CPU isolation is more narrowly focused compared to generic cpuset based control.

-Xi