From: Yicong Yang <yangyicong@hisilicon.com>
On building the topology from the devicetree, we've already gotten the
SMT thread number of each core. Update the largest SMT thread number
and enable the SMT control by the end of topology parsing.
The framework's SMT control provides two interface to the users [1]
through /sys/devices/system/cpu/smt/control:
1) enable SMT by writing "on" and disable by "off"
2) enable SMT by writing max_thread_number or disable by writing 1
Both method support to completely disable/enable the SMT cores so both
work correctly for symmetric SMT platform and asymmetric platform with
non-SMT and one type SMT cores like:
core A: 1 thread
core B: X (X!=1) threads
Note that for a theoretically possible multiple SMT-X (X>1) core
platform the SMT control is also supported as expected but only
by writing the "on/off" method.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/sysfs-devices-system-cpu#n542
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
---
drivers/base/arch_topology.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
index 3ebe77566788..d409d323ee64 100644
--- a/drivers/base/arch_topology.c
+++ b/drivers/base/arch_topology.c
@@ -11,6 +11,7 @@
#include <linux/cleanup.h>
#include <linux/cpu.h>
#include <linux/cpufreq.h>
+#include <linux/cpu_smt.h>
#include <linux/device.h>
#include <linux/of.h>
#include <linux/slab.h>
@@ -506,6 +507,10 @@ core_initcall(free_raw_capacity);
#endif
#if defined(CONFIG_ARM64) || defined(CONFIG_RISCV)
+
+/* Used to enable the SMT control */
+static unsigned int max_smt_thread_num = 1;
+
/*
* This function returns the logic cpu number of the node.
* There are basically three kinds of return values:
@@ -565,6 +570,8 @@ static int __init parse_core(struct device_node *core, int package_id,
i++;
} while (1);
+ max_smt_thread_num = max_t(unsigned int, max_smt_thread_num, i);
+
cpu = get_cpu_for_node(core);
if (cpu >= 0) {
if (!leaf) {
@@ -677,6 +684,17 @@ static int __init parse_socket(struct device_node *socket)
if (!has_socket)
ret = parse_cluster(socket, 0, -1, 0);
+ /*
+ * Reset the max_smt_thread_num to 1 on failure. Since on failure
+ * we need to notify the framework the SMT is not supported, but
+ * max_smt_thread_num can be initialized to the SMT thread number
+ * of the cores which are successfully parsed.
+ */
+ if (ret)
+ max_smt_thread_num = 1;
+
+ cpu_smt_set_num_threads(max_smt_thread_num, max_smt_thread_num);
+
return ret;
}
--
2.24.0On 11/03/2025 08:51, Yicong Yang wrote:
> From: Yicong Yang <yangyicong@hisilicon.com>
>
> On building the topology from the devicetree, we've already gotten the
> SMT thread number of each core. Update the largest SMT thread number
> and enable the SMT control by the end of topology parsing.
>
> The framework's SMT control provides two interface to the users [1]
> through /sys/devices/system/cpu/smt/control:
> 1) enable SMT by writing "on" and disable by "off"
> 2) enable SMT by writing max_thread_number or disable by writing 1
>
> Both method support to completely disable/enable the SMT cores so both
> work correctly for symmetric SMT platform and asymmetric platform with
> non-SMT and one type SMT cores like:
> core A: 1 thread
> core B: X (X!=1) threads
>
> Note that for a theoretically possible multiple SMT-X (X>1) core
> platform the SMT control is also supported as expected but only
> by writing the "on/off" method.
Here we still have a little misunderstanding. IMHO, even on such a
system 2) would work too.
My qemu example with SMT-1, SMT-2 and SMT-4 in one system from your v11:
# cat /proc/schedstat | grep -v "^v\|^t" | awk '{print $1" "$2" "$3}'
cpu0 0 0
domain0 MC ff
cpu1 0 0
domain0 MC ff
cpu2 0 0
domain0 SMT 0c
domain1 MC ff
cpu3 0 0
domain0 SMT 0c
domain1 MC ff
cpu4 0 0
domain0 SMT f0
domain1 MC ff
cpu5 0 0
domain0 SMT f0
domain1 MC ff
cpu6 0 0
domain0 SMT f0
domain1 MC ff
cpu7 0 0
domain0 SMT f0
domain1 MC ff
# cat /proc/cpuinfo | grep ^processor
processor : 0
processor : 1
processor : 2
processor : 3
processor : 4
processor : 5
processor : 6
processor : 7
# echo 1 > /sys/devices/system/cpu/smt/control
# cat /proc/cpuinfo | grep ^processor
processor : 0
processor : 1
processor : 2
processor : 4
# echo 4 > /sys/devices/system/cpu/smt/control
# cat /proc/cpuinfo | grep ^processor
processor : 0
processor : 1
processor : 2
processor : 3
processor : 4
processor : 5
processor : 6
processor : 7
Whats doesn't work is to echoing a '2' but that's not
'max_thread_number' of the system.
[...]
On 2025/3/17 17:56, Dietmar Eggemann wrote:
> On 11/03/2025 08:51, Yicong Yang wrote:
>> From: Yicong Yang <yangyicong@hisilicon.com>
>>
>> On building the topology from the devicetree, we've already gotten the
>> SMT thread number of each core. Update the largest SMT thread number
>> and enable the SMT control by the end of topology parsing.
>>
>> The framework's SMT control provides two interface to the users [1]
>> through /sys/devices/system/cpu/smt/control:
>> 1) enable SMT by writing "on" and disable by "off"
>> 2) enable SMT by writing max_thread_number or disable by writing 1
>>
>> Both method support to completely disable/enable the SMT cores so both
>> work correctly for symmetric SMT platform and asymmetric platform with
>> non-SMT and one type SMT cores like:
>> core A: 1 thread
>> core B: X (X!=1) threads
>>
>> Note that for a theoretically possible multiple SMT-X (X>1) core
>> platform the SMT control is also supported as expected but only
>> by writing the "on/off" method.
>
> Here we still have a little misunderstanding. IMHO, even on such a
> system 2) would work too.
>
yes but only by writing the max_thread_number. e.g. a system with SMT number
of 1 (no SMT core), X, Y (Y > X), 1 works same as "off" and Y works same as
"on", as you shown below. write X will be blocked by the CPU framework:
estuary:/sys/devices/system/cpu/smt$ cat control
off
# emulated CPU 0-7,16-22 as SMT-2, CPU 8-11,24-27 as SMT-4
estuary:/sys/devices/system/cpu/smt$ cat ../online
0,2,4,6,8,12-16,18,20,22,24,28-31
estuary:/sys/devices/system/cpu/smt$ echo 2 > control
bash: echo: write error: Invalid argument
estuary:/sys/devices/system/cpu/smt$ echo 4 > control
estuary:/sys/devices/system/cpu/smt$ cat ../online
0-31
so method 1) will always match the expectation to fully enable/disable the
SMT on all cores, that's I mean here. But 2) won't work if user expected
to write 2 to enable SMT-2 (I think it'll will work if we support
CONFIG_SMT_NUM_THREADS_DYNAMIC on arm64 later).
Thanks.
> My qemu example with SMT-1, SMT-2 and SMT-4 in one system from your v11:
>
> # cat /proc/schedstat | grep -v "^v\|^t" | awk '{print $1" "$2" "$3}'
> cpu0 0 0
> domain0 MC ff
> cpu1 0 0
> domain0 MC ff
> cpu2 0 0
> domain0 SMT 0c
> domain1 MC ff
> cpu3 0 0
> domain0 SMT 0c
> domain1 MC ff
> cpu4 0 0
> domain0 SMT f0
> domain1 MC ff
> cpu5 0 0
> domain0 SMT f0
> domain1 MC ff
> cpu6 0 0
> domain0 SMT f0
> domain1 MC ff
> cpu7 0 0
> domain0 SMT f0
> domain1 MC ff
>
> # cat /proc/cpuinfo | grep ^processor
> processor : 0
> processor : 1
> processor : 2
> processor : 3
> processor : 4
> processor : 5
> processor : 6
> processor : 7
>
> # echo 1 > /sys/devices/system/cpu/smt/control
>
> # cat /proc/cpuinfo | grep ^processor
> processor : 0
> processor : 1
> processor : 2
> processor : 4
>
> # echo 4 > /sys/devices/system/cpu/smt/control
>
> # cat /proc/cpuinfo | grep ^processor
> processor : 0
> processor : 1
> processor : 2
> processor : 3
> processor : 4
> processor : 5
> processor : 6
> processor : 7
>
> Whats doesn't work is to echoing a '2' but that's not
> 'max_thread_number' of the system.
>
> [...]
>
> .
>
On 17/03/2025 12:29, Yicong Yang wrote: > On 2025/3/17 17:56, Dietmar Eggemann wrote: >> On 11/03/2025 08:51, Yicong Yang wrote: >>> From: Yicong Yang <yangyicong@hisilicon.com> [...] >>> Both method support to completely disable/enable the SMT cores so both >>> work correctly for symmetric SMT platform and asymmetric platform with >>> non-SMT and one type SMT cores like: >>> core A: 1 thread >>> core B: X (X!=1) threads >>> >>> Note that for a theoretically possible multiple SMT-X (X>1) core >>> platform the SMT control is also supported as expected but only >>> by writing the "on/off" method. >> >> Here we still have a little misunderstanding. IMHO, even on such a >> system 2) would work too. >> > > > yes but only by writing the max_thread_number. e.g. a system with SMT number > of 1 (no SMT core), X, Y (Y > X), 1 works same as "off" and Y works same as > "on", as you shown below. write X will be blocked by the CPU framework: > estuary:/sys/devices/system/cpu/smt$ cat control > off > # emulated CPU 0-7,16-22 as SMT-2, CPU 8-11,24-27 as SMT-4 > estuary:/sys/devices/system/cpu/smt$ cat ../online > 0,2,4,6,8,12-16,18,20,22,24,28-31 > estuary:/sys/devices/system/cpu/smt$ echo 2 > control > bash: echo: write error: Invalid argument > estuary:/sys/devices/system/cpu/smt$ echo 4 > control > estuary:/sys/devices/system/cpu/smt$ cat ../online > 0-31 > > so method 1) will always match the expectation to fully enable/disable the > SMT on all cores, that's I mean here. But 2) won't work if user expected > to write 2 to enable SMT-2 (I think it'll will work if we support > CONFIG_SMT_NUM_THREADS_DYNAMIC on arm64 later). OK, looks like you're aware of this then. Just saying that technically '4' would be the max thread number of the system and not '2' so it still looks OK from this perspective. But OK, we don't have those systems now anyway. [...]
On Tue, 11 Mar 2025 15:51:41 +0800 Yicong Yang <yangyicong@huawei.com> wrote: > From: Yicong Yang <yangyicong@hisilicon.com> > > On building the topology from the devicetree, we've already gotten the > SMT thread number of each core. Update the largest SMT thread number > and enable the SMT control by the end of topology parsing. > > The framework's SMT control provides two interface to the users [1] > through /sys/devices/system/cpu/smt/control: > 1) enable SMT by writing "on" and disable by "off" > 2) enable SMT by writing max_thread_number or disable by writing 1 > > Both method support to completely disable/enable the SMT cores so both > work correctly for symmetric SMT platform and asymmetric platform with > non-SMT and one type SMT cores like: > core A: 1 thread > core B: X (X!=1) threads > > Note that for a theoretically possible multiple SMT-X (X>1) core > platform the SMT control is also supported as expected but only > by writing the "on/off" method. > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/sysfs-devices-system-cpu#n542 > Reviewed-by: Pierre Gondois <pierre.gondois@arm.com> > Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com> > Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
On Tue, Mar 11, 2025 at 03:51:41PM +0800, Yicong Yang wrote: > From: Yicong Yang <yangyicong@hisilicon.com> > > On building the topology from the devicetree, we've already gotten the > SMT thread number of each core. Update the largest SMT thread number > and enable the SMT control by the end of topology parsing. > > The framework's SMT control provides two interface to the users [1] > through /sys/devices/system/cpu/smt/control: > 1) enable SMT by writing "on" and disable by "off" > 2) enable SMT by writing max_thread_number or disable by writing 1 > > Both method support to completely disable/enable the SMT cores so both > work correctly for symmetric SMT platform and asymmetric platform with > non-SMT and one type SMT cores like: > core A: 1 thread > core B: X (X!=1) threads > > Note that for a theoretically possible multiple SMT-X (X>1) core > platform the SMT control is also supported as expected but only > by writing the "on/off" method. > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/testing/sysfs-devices-system-cpu#n542 Just the path must suffice here, no need for URL. LGTM otherwise, much simple now: Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> -- Regards, Sudeep
© 2016 - 2025 Red Hat, Inc.