linux-kernel - Re: [PATCH] arm64: defconfig: enable 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20250821-sloppy-urchin-of-fantasy-ecc4ce@sudeepholla>
Date: Thu, 21 Aug 2025 13:11:46 +0100
From: Sudeep Holla <sudeep.holla@....com>
To: "Christoph Lameter (Ampere)" <cl@...two.org>
Cc: Jeremy Linton <jeremy.linton@....com>,
	Huang Shijie <shijie@...amperecomputing.com>,
	Sudeep Holla <sudeep.holla@....com>, catalin.marinas@....com,
	will@...nel.org, patches@...erecomputing.com,
	Shubhang@...amperecomputing.com, krzysztof.kozlowski@...aro.org,
	bjorn.andersson@....qualcomm.com, geert+renesas@...der.be,
	arnd@...db.de, nm@...com, ebiggers@...nel.org,
	nfraprado@...labora.com, prabhakar.mahadev-lad.rj@...renesas.com,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: defconfig: enable CONFIG_SCHED_CLUSTER

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 MC
> > > 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. This
> > > 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)

> Please make arm64 work like the other Linux platforms and do not introduce
> special handling for ARM64.

Again I am not suggesting that and we never want that.

-- 
Regards,
Sudeep