Message-Id: <20260120225904.2206939-1-ankur.a.arora@oracle.com>
Date: Tue, 20 Jan 2026 14:59:04 -0800
From: Ankur Arora <ankur.a.arora@...cle.com>
To: sudeep.holla@....com
Cc: Shubhang@...amperecomputing.com, arnd@...db.de,
        bjorn.andersson@....qualcomm.com, catalin.marinas@....com,
        cl@...two.org, ebiggers@...nel.org, geert+renesas@...der.be,
        jeremy.linton@....com, krzysztof.kozlowski@...aro.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        nfraprado@...labora.com, nm@...com, patches@...erecomputing.com,
        prabhakar.mahadev-lad.rj@...renesas.com, shijie@...amperecomputing.com,
        will@...nel.org, Ankur Arora <ankur.a.arora@...cle.com>
Subject: Re: [PATCH] arm64: defconfig: enable CONFIG_SCHED_CLUSTER

Suddep Holla <sudeep.holla@....com> writes:

> On Wed, Aug 20, 2025 at 04:44:29PM -0700, Christoph Lameter (Ampere) wrote:
> > On Mon, 18 Aug 2025, Sudeep Holla wrote:
> >
> > > > But returning to the original point, its not clear to me that the HW
> > > > 'cluster' information is really causing the performance boost vs, just
> > > > having a medium size scheduling domain (aka just picking an arbitrary size
> > > > 4-16 cores) under MC, or simply 'slicing' a L3 in the PPTT such that the M
> C
> > > > domains are smaller, yields the same effect. I've seen a number of cases
> > > > where 'lying' about the topology yields a better result in a benchmark. Th
> is
> > > > is largely what is happening with these Firmware toggles that move/remove
> > > > the NUMA domains too. Being able to manually reconfigure some of these
> > > > scheduling levels at runtime might be useful...
> > > >
> > >
> > > I share your concern and hence completely again representation of any fake
> > > data in the ACPI topology just to get improved performance. Yes we have seen
> > > that in the past.
> >
> > Depends on what you call fake. There are microarchitectural issues
> > regarding the proximity of the processors that the customer may not know
> > about and therefore the data provides by the vendor may be considered
> > "fake". Certainly that is not the case for our processors.
> 
> Fair enough. We have seen systems with fake data as those data seem to
> accidentally improve performance.
> 
> > This is a common feature and widely available on other platforms.
> > There is no need to do anything but enable the functionality. Having a
> > special version of ACPI for arm64 or a special handling for arm64 does not
> > make sense.
> >
> 
> I am not suggesting to make it any special on Arm64, we would never want
> that unless absolutely needed and this is not one such thing.
> 
> > The ACPI subsystem provides the ability to add blacklists. If a vendor has
> > problems with their firmward providing data that reduces the performance
> > and is unable to fix it othereise then the vendor can use that feature to
> > disable these ACPI features for their platform by submitting a patch.
> >
> 
> I don't have a strong opinion on that approach. IIUC, maintaining list
> needs change in the kernel which Jeremy mentioned is not what distro
> prefer over command line parameter. We can always have a parameter to
> disable the feature and keep the build config enabled as in this patch.
> So only platforms that have performance issue by enabling this will have
> to add the command line parameter(hopefully that works for all)

Resurrecting this old thread.

We enable CONFIG_SCHED_CLUSTER by default on Oracle UEK kernels. And,
this thread didn't really come to a consensus, but I'm trying to figure
out what's the best approach if we want to enable this by default?

Thanks
--
ankur

Powered by blists - more mailing lists