[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ttxjaonc.fsf@mpe.ellerman.id.au>
Date: Thu, 13 Apr 2023 23:37:59 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: Laurent Dufour <ldufour@...ux.ibm.com>, npiggin@...il.com,
christophe.leroy@...roup.eu
Cc: msuchanek@...e.de, nathanl@...ux.ibm.com,
linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Subject: Re: [PATCH 1/2] pseries/smp: export the smt level in the SYS FS.
Hi Laurent,
Laurent Dufour <ldufour@...ux.ibm.com> writes:
> There is no SMT level recorded in the kernel neither in user space.
> Indeed there is no real constraint about that and mixed SMT levels are
> allowed and system is working fine this way.
>
> However when new CPU are added, the kernel is onlining all the threads
> which is leading to mixed SMT levels and confuse end user a bit.
>
> To prevent this exports a SMT level from the kernel so user space
> application like the energy daemon, could read it to adjust their settings.
> There is no action unless recording the value when a SMT value is written
> into the new sysfs entry. User space applications like ppc64_cpu should
> update the sysfs when changing the SMT level to keep the system consistent.
>
> Suggested-by: Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
> Signed-off-by: Laurent Dufour <ldufour@...ux.ibm.com>
> ---
> arch/powerpc/platforms/pseries/pseries.h | 3 ++
> arch/powerpc/platforms/pseries/smp.c | 39 ++++++++++++++++++++++++
> 2 files changed, 42 insertions(+)
There is a generic sysfs interface for smt in /sys/devices/system/cpu/smt
I think we should be enabling that on powerpc and then adapting it to
our needs, rather than adding a pseries specific file.
Currently the generic code is only aware of SMT on/off, so it would need
to be taught about SMT4 and 8 at least.
There are already hooks in the generic code to check the SMT level when
bringing CPUs up, see cpu_smt_allowed(), they may work for the pseries
hotplug case too, though maybe we need some additional logic.
Wiring up the basic support is pretty straight forward, something like
the diff below.
cheers
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 0f123f1f62a1..a48576f1c579 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -260,6 +260,7 @@ config PPC
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_VIRT_CPU_ACCOUNTING
select HAVE_VIRT_CPU_ACCOUNTING_GEN
+ select HOTPLUG_SMT if HOTPLUG_CPU
select HUGETLB_PAGE_SIZE_VARIABLE if PPC_BOOK3S_64 && HUGETLB_PAGE
select IOMMU_HELPER if PPC64
select IRQ_DOMAIN
diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
index 8a4d4f4d9749..bd23ba716d23 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -143,5 +143,8 @@ static inline int cpu_to_coregroup_id(int cpu)
#endif
#endif
+bool topology_is_primary_thread(unsigned int cpu);
+bool topology_smt_supported(void);
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_TOPOLOGY_H */
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 265801a3e94c..8619609809d5 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -1769,4 +1769,20 @@ void __noreturn arch_cpu_idle_dead(void)
start_secondary_resume();
}
+/**
+ * topology_is_primary_thread - Check whether CPU is the primary SMT thread
+ * @cpu: CPU to check
+ */
+bool topology_is_primary_thread(unsigned int cpu)
+{
+ return cpu == cpu_first_thread_sibling(cpu);
+}
+
+/**
+ * topology_smt_supported - Check whether SMT is supported by the CPUs
+ */
+bool topology_smt_supported(void)
+{
+ return threads_per_core > 1;
+}
#endif
Powered by blists - more mailing lists