linux-kernel - Re: [PATCH v7 4/8] powerpc/smp: Introduce CONFIG_SCHED

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20250826080706.GC3245006@noisy.programming.kicks-ass.net>
Date: Tue, 26 Aug 2025 10:07:06 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Christophe Leroy <christophe.leroy@...roup.eu>
Cc: K Prateek Nayak <kprateek.nayak@....com>,
	Madhavan Srinivasan <maddy@...ux.ibm.com>,
	Michael Ellerman <mpe@...erman.id.au>,
	Nicholas Piggin <npiggin@...il.com>,
	Heiko Carstens <hca@...ux.ibm.com>,
	Vasily Gorbik <gor@...ux.ibm.com>,
	Alexander Gordeev <agordeev@...ux.ibm.com>,
	Christian Borntraeger <borntraeger@...ux.ibm.com>,
	Sven Schnelle <svens@...ux.ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>,
	Juri Lelli <juri.lelli@...hat.com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	linux-s390@...r.kernel.org,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
	Valentin Schneider <vschneid@...hat.com>,
	thomas.weissschuh@...utronix.de, Li Chen <chenl311@...natelecom.cn>,
	Bibo Mao <maobibo@...ngson.cn>, Mete Durlu <meted@...ux.ibm.com>,
	Tobias Huschle <huschle@...ux.ibm.com>,
	Easwar Hariharan <easwar.hariharan@...ux.microsoft.com>,
	Guo Weikang <guoweikang.kernel@...il.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Brian Gerst <brgerst@...il.com>,
	Patryk Wlazlyn <patryk.wlazlyn@...ux.intel.com>,
	Swapnil Sapkal <swapnil.sapkal@....com>,
	"Yury Norov [NVIDIA]" <yury.norov@...il.com>,
	Sudeep Holla <sudeep.holla@....com>,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	Andrea Righi <arighi@...dia.com>,
	Yicong Yang <yangyicong@...ilicon.com>,
	Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>,
	Tim Chen <tim.c.chen@...ux.intel.com>,
	Vinicius Costa Gomes <vinicius.gomes@...el.com>
Subject: Re: [PATCH v7 4/8] powerpc/smp: Introduce CONFIG_SCHED_MC to guard
 MC scheduling bits

On Tue, Aug 26, 2025 at 06:49:29AM +0200, Christophe Leroy wrote:
> 
> 
> Le 26/08/2025 à 06:13, K Prateek Nayak a écrit :
> > PowerPC enables the MC scheduling domain by default on systems with
> > coregroup support without having a SCHED_MC config in Kconfig.
> > 
> > The scheduler uses CONFIG_SCHED_MC to introduce the MC domain in the
> > default topology (core) and to optimize the default CPU selection
> > routine (sched-ext).
> > 
> > Introduce CONFIG_SCHED_MC for powerpc and note that it should be
> > preferably enabled given the current default behavior. This also ensures
> > PowerPC is tested during future developments that come to depend on
> > CONFIG_SCHED_MC.
> > 
> > Signed-off-by: K Prateek Nayak <kprateek.nayak@....com>
> > ---
> >   arch/powerpc/Kconfig           | 9 +++++++++
> >   arch/powerpc/include/asm/smp.h | 2 ++
> >   arch/powerpc/kernel/smp.c      | 4 ++++
> >   3 files changed, 15 insertions(+)
> > 
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index 93402a1d9c9f..e954ab3f635f 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -971,6 +971,15 @@ config SCHED_SMT
> >   	  when dealing with POWER5 cpus at a cost of slightly increased
> >   	  overhead in some places. If unsure say N here.
> > +config SCHED_MC
> > +	bool "Multi-Core Cache (MC) scheduler support"
> > +	depends on PPC64 && SMP
> > +	default y
> > +	help
> > +	  MC scheduler support improves the CPU scheduler's decision making
> > +	  when dealing with POWER systems that contain multiple Last Level
> > +	  Cache instances on the same socket. If unsure say Y here.
> > +
> 
> You shouldn't duplicate CONFIG_SCHED_MC in every architecture, instead you
> should define a CONFIG_ARCH_HAS_SCHED_MC in arch/Kconfig that gets selected
> by architectures then have CONFIG_SCHED_MC defined in init/Kconfig or
> kernel/Kconfig or so.

Let me add this first -- it is currently duplicated. Then I'll see about
merging the thing across architectures.