[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2d9259e4-1b58-435d-bf02-9c4badd52fd9@arm.com>
Date: Tue, 12 Aug 2025 12:32:36 -0500
From: Jeremy Linton <jeremy.linton@....com>
To: "Christoph Lameter (Ampere)" <cl@...two.org>
Cc: 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 8/12/25 11:33 AM, Christoph Lameter (Ampere) wrote:
> On Mon, 11 Aug 2025, Jeremy Linton wrote:
>
>> From what I've seen, SCHED_CLUSTER seems to be a bit of give and take
>> depending on benchmark and machine. I'm not sure if it should be default
>> enabled or not, but it would really be nice to have at least a larger sweep of
>> benchmarks/machines in order to be sure of the decision.
>
> If the hardware provides a clusterid then I think this clusterid should be
> used for the sched domains. CONFIG_SCHED_CLUSTER does that. So it should
> be the default.
Hi,
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.
>
> If there is no cluster information then these domains should not be
> created. I think that is already the case?
>
>
Powered by blists - more mailing lists