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: <97278200-b877-47a6-84d4-34ea9dda4e6b@gentwo.org>
Date: Thu, 14 Aug 2025 09:30:06 -0700 (PDT)
From: "Christoph Lameter (Ampere)" <cl@...two.org>
To: Sudeep Holla <sudeep.holla@....com>
cc: Jeremy Linton <jeremy.linton@....com>, 
    Huang Shijie <shijie@...amperecomputing.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 Thu, 14 Aug 2025, Sudeep Holla wrote:

>   |  Different architectures use different terminology to denominate logically
>   |  associated processors, but terms such as package, cluster, module, and
>   |  socket are typical examples.
>
> So how can one use these across architectures ? Package/Socket is quite
> standard. Cluster can be group of processors or it can also be group of
> processor clusters. One of the Arm vendors call it super cluster or something.
> All these makes it super hard for a generic OS to interpret that information.
> Just CONFIG_SCHED_CLUSTER was added with one notion of cluster which was soon
> realised doesn't match with some other notion of it.

What the cluster actually is used for is up to the hardware. The linux
scheduler provides this functionality. How and when this feature is used
by firmware is a vendor issue. There was never a clear definition.

> We can enable it and I am sure someone will report a regression on their
> platform and we need to disable it again. The benchmark doesn't purely
> depend on just the "notion" of cluster but it is often related to the
> private resource and how they are shared in the system. So even if you
> strictly follow the notion of cluster as supported by CONFIG_SCHED_CLUSTER
> it will fail on systems where the private resources are shared across the
> "cluster" boundaries or some variant configuration.

That is not our problem. If the vendor provides clustering information and
the scheduler uses that then the vendor can modify the firmware to not
enable clustering.

As mentioned before: We could create a blacklist to override the ACPI info
from the vendor to ensure that clustering is off.

What we should not do is disabling clustering for all.

> > We could add a blacklist for those platforms to avoid regressions but we
> > should not allow that to hinder us to enable full support for clustering
> > on ARM64.
> >
>
> Sure, but we need to improve the "cluster" definition in the ACPI and Arm
> specification, get an agreement on what it means for other architecture
> first IMO. We don't want to revisit the same topic again without these as
> IIRC this is the second time we are discussion around this topic.

The vendors need flexibility to use this feature when it makes sense.

Having a clear definition would limit the use of clustering feature and
limits innovation. Vendors can control the clustering via ACPI and the
firmware they provide with their system.

We could change definition but that but that would be a decadelong
process which will encounter resistance from vendors that make uses of the
clustering feature that does not fall into the stricter definition.