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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOBoifiv2GCeeDjax8Famu7atgkGNV0ZxxG-cfgvC857-dniqA@mail.gmail.com>
Date: Wed, 7 May 2025 13:07:16 -0700
From: Xi Wang <xii@...gle.com>
To: Tejun Heo <tj@...nel.org>
Cc: Frederic Weisbecker <frederic@...nel.org>, 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>, 
	Johannes Weiner <hannes@...xchg.org>, Michal Koutný <mkoutny@...e.com>, 
	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>, 
	jiangshanlai@...il.com
Subject: Re: [RFC/PATCH] sched: Support moving kthreads into cpuset cgroups

On Wed, May 7, 2025 at 10:36 AM Tejun Heo <tj@...nel.org> wrote:
>
> Hello,
>
> On Wed, May 07, 2025 at 10:23:24AM -0700, Xi Wang wrote:
> > Overall I think your arguments depend on kernel and application threads are
> > significantly different for cpu affinity management, but there isn't enough
> > evidence for it. If cpuset is a bad idea for kernel threads it's probably not
> > a good idea for user threads either. Maybe we should just remove cpuset from
> > kernel and let applications threads go with boot time global variables and
> > set their own cpu affinities.
>
> I can't tell whether you're making a good faith argument. Even if you are,
> you're making one bold claim without much substance and then jumping to the
> other extreme based on that. This isn't a productive way to discuss these
> things.
>
> Thanks.
>
> --
> tejun

Yes this is still serious technical discussion. Frederic made several "we can't
have b because we already have / are working on a" statements which were not
very actionable. Deducing to a particular case is a quick way to simplify. I'd
prefer to focus more on higher level technical tradeoffs.

Overall compartmentalization limits resource (cpu) sharing which limits
overcommit thus efficiency. cpumask restrictions are not ideal but sometimes
necessary. Dynamically configurable cpumasks are better than statically
reserved cpus.

I do think the cgroup tree structure sometimes helps and we don't have to use
it for all cases.

-Xi