[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d172f30d-28ad-dd46-1385-f010107bc789@gentwo.org>
Date: Wed, 13 Aug 2025 08:55:36 -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 Wed, 13 Aug 2025, Sudeep Holla wrote:
> > The problem is that this information is being sourced from the ACPI PPTT.
> > The ACPI specification (AFAIK) doesn't define a cluster, so the linux
> > cluster information is being 'invented' based on however the firmware vendor
> > choose to group CPU nodes in the PPTT. Which means its possible for them to
> > unknowingly create clusters, or also fail to create them when they make
> > sense.
>
> +1, completely agree. As Jeremy mentioned, it is hit or miss and cluster
> is loosely defined and IIRC Huawei pushed this based on their platform at
> the time and it did break some benchmarks on few other platforms. So it
> is not a good idea to make it default config IMO.
Can we figure out which platforms benchmarks were affected and why?
It seems the notion of a "cluster" on ARM64 is derived (I guess a better
word than "invented" hehe) from sibling information instead of PPTT. But
using that information should work fine right?
Powered by blists - more mailing lists