[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231211131612.GB25681@willie-the-truck>
Date: Mon, 11 Dec 2023 13:16:12 +0000
From: Will Deacon <will@...nel.org>
To: Yicong Yang <yangyicong@...wei.com>
Cc: catalin.marinas@....com, sudeep.holla@....com,
linux-arm-kernel@...ts.infradead.org, dietmar.eggemann@....com,
gregkh@...uxfoundation.org, rafael@...nel.org,
jonathan.cameron@...wei.com, prime.zeng@...ilicon.com,
linuxarm@...wei.com, yangyicong@...ilicon.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 0/4] Support SMT control on arm64
On Tue, Nov 21, 2023 at 05:25:58PM +0800, Yicong Yang wrote:
> From: Yicong Yang <yangyicong@...ilicon.com>
>
> The core CPU control framework supports runtime SMT control which
> is not yet supported on arm64. Besides the general vulnerabilities
> concerns we want this runtime control on our arm64 server for:
>
> - better single CPU performance in some cases
> - saving overall power consumption
>
> This patchset implements it in the following aspects:
>
> - implements the basic support in arch_topology driver
> - support retrieve SMT thread number on OF based system
> - support retrieve SMT thread number on ACPI based system
> - select HOTPLUG_SMT for arm64
>
> Tests has been done on our real ACPI based arm64 server and on
> ACPI/OF based QEMU VMs.
>
> The patchset is based on v6.7-rc1.
>
> Change since v3:
> - Fix some build and kconfig error reported by kernel test robot <lkp@...el.com>
> Link: https://lore.kernel.org/linux-arm-kernel/20231114040110.54590-1-yangyicong@huawei.com/
>
> Change since v2:
> - Detect SMT thread number at topology build from ACPI/DT, avoid looping CPUs
> - Split patches into ACPI/OF/arch_topology path and enable the kconfig for arm64
> Link: https://lore.kernel.org/linux-arm-kernel/20231010115335.13862-1-yangyicong@huawei.com/
>
> Yicong Yang (4):
> arch_topology: Support basic SMT control for the driver
> arch_topology: Support SMT control for OF based system
Looking at the first two patches you have here, they are incredibly trivial
and feel like they'd be better off implemented as the default behaviour in
the core code so that architectures with additional constraints (e.g. x86)
can override that.
Will
Powered by blists - more mailing lists