linux-kernel - Re: [PATCH v4 0/4] Support SMT control on arm64

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 14 Dec 2023 19:39:51 +0800
From:   Yicong Yang <yangyicong@...wei.com>
To:     Will Deacon <will@...nel.org>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        <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>, <linux-kernel@...r.kernel.org>,
        <yangyicong@...ilicon.com>
Subject: Re: [PATCH v4 0/4] Support SMT control on arm64

Hi Will,

On 2023/12/11 21:16, Will Deacon wrote:
> 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.
> 

Loop Thomas and Peter in and expect some hint on the SMT HOTPLUG implementation.

Thanks for the comments. I'm a bit uncertain of some points.

Currently the framework requires the architeture provide 2 things to enable HOTPLUG_SMT:
1. In the init stage of the arch code, use cpu_smt_set_num_threads() to tell the framework
   SMT is supported or not and how many threads are within a core.
2. topology_is_primary_thread() to indicate one CPU can be offline or not, when disable SMT.

For the 2nd point, it's possible to provide a weak function in the framework if no special
requirement for the "primary" SMT thread, just make the 1st CPU in a physical core as the
primary thread like what implemented in this patchset for amr64. And let architectures like
x86/powerpc to provides override function for special purpose.

For the 1st point I'm not sure it could/should be done in the framework since we can got this
SMT information only in the init stage after we parsing the topology which is rather architecture
specific. On arm64 we may gain this after parsing the devicetree or ACPI and on x86 they gain
this by CPUID. It's hard to provide a default way for detecting this. So in this patchset the
SMT information is detected separately in the ACPI/OF topology parsing.

Thanks.