| Message ID | 20230629143149.79073-1-ldufour@linux.ibm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Introduce SMT level and add PowerPC support | expand |
> On 29-Jun-2023, at 8:01 PM, Laurent Dufour <ldufour@linux.ibm.com> wrote: > > I'm taking over the series Michael sent previously [1] which is smartly > reviewing the initial series I sent [2]. This series is addressing the > comments sent by Thomas and me on the Michael's one. > > Here is a short introduction to the issue this series is addressing: > > When a new CPU is added, the kernel is activating all its threads. This > leads to weird, but functional, result when adding CPU on a SMT 4 system > for instance. > > Here the newly added CPU 1 has 8 threads while the other one has 4 threads > active (system has been booted with the 'smt-enabled=4' kernel option): > > ltcden3-lp12:~ # ppc64_cpu --info > Core 0: 0* 1* 2* 3* 4 5 6 7 > Core 1: 8* 9* 10* 11* 12* 13* 14* 15* > > This mixed SMT level may confused end users and/or some applications. > > There is no SMT level recorded in the kernel (common code), neither in user > space, as far as I know. Such a level is helpful when adding new CPU or > when optimizing the energy efficiency (when reactivating CPUs). > > When SMP and HOTPLUG_SMT are defined, this series is adding a new SMT level > (cpu_smt_num_threads) and few callbacks allowing the architecture code to > fine control this value, setting a max and a "at boot" level, and > controling whether a thread should be onlined or not. > > v3: > Fix a build error in the patch 6/9 Successfully tested the V3 version on a Power10 LPAR. Add/remove of processor core worked correctly, preserving the SMT level (on a kernel booted with smt-enabled= parameter) Laurent (Thanks!) also provided a patch to update the ppc64_cpu & lparstat utility. With patched ppc64_cpu utility verified that SMT level changed at runtime was preserved across processor core add (on a kernel booted without smt-enabled= parameter) Based on these test results Tested-by: Sachin Sant <sachinp@linux.ibm.com> - Sachin
Le 30/06/2023 à 15:32, Sachin Sant a écrit : > > >> On 29-Jun-2023, at 8:01 PM, Laurent Dufour <ldufour@linux.ibm.com> wrote: >> >> I'm taking over the series Michael sent previously [1] which is smartly >> reviewing the initial series I sent [2]. This series is addressing the >> comments sent by Thomas and me on the Michael's one. >> >> Here is a short introduction to the issue this series is addressing: >> >> When a new CPU is added, the kernel is activating all its threads. This >> leads to weird, but functional, result when adding CPU on a SMT 4 system >> for instance. >> >> Here the newly added CPU 1 has 8 threads while the other one has 4 threads >> active (system has been booted with the 'smt-enabled=4' kernel option): >> >> ltcden3-lp12:~ # ppc64_cpu --info >> Core 0: 0* 1* 2* 3* 4 5 6 7 >> Core 1: 8* 9* 10* 11* 12* 13* 14* 15* >> >> This mixed SMT level may confused end users and/or some applications. >> >> There is no SMT level recorded in the kernel (common code), neither in user >> space, as far as I know. Such a level is helpful when adding new CPU or >> when optimizing the energy efficiency (when reactivating CPUs). >> >> When SMP and HOTPLUG_SMT are defined, this series is adding a new SMT level >> (cpu_smt_num_threads) and few callbacks allowing the architecture code to >> fine control this value, setting a max and a "at boot" level, and >> controling whether a thread should be onlined or not. >> >> v3: >> Fix a build error in the patch 6/9 > > Successfully tested the V3 version on a Power10 LPAR. Add/remove of > processor core worked correctly, preserving the SMT level (on a kernel > booted with smt-enabled= parameter) > > Laurent (Thanks!) also provided a patch to update the ppc64_cpu & > lparstat utility. With patched ppc64_cpu utility verified that SMT level > changed at runtime was preserved across processor core add (on > a kernel booted without smt-enabled= parameter) > > Based on these test results > > Tested-by: Sachin Sant <sachinp@linux.ibm.com> Thanks a lot, Sachin! Once this series is accepted, I'll send the series to update ppc64_cpu.
Hi, Laurent, I want to test this patch set and found that it does not apply on top of latest usptream git, because of some changes in this merge window, so better rebase. thanks, rui On Thu, 2023-06-29 at 16:31 +0200, Laurent Dufour wrote: > I'm taking over the series Michael sent previously [1] which is > smartly > reviewing the initial series I sent [2]. This series is addressing > the > comments sent by Thomas and me on the Michael's one. > > Here is a short introduction to the issue this series is addressing: > > When a new CPU is added, the kernel is activating all its threads. > This > leads to weird, but functional, result when adding CPU on a SMT 4 > system > for instance. > > Here the newly added CPU 1 has 8 threads while the other one has 4 > threads > active (system has been booted with the 'smt-enabled=4' kernel > option): > > ltcden3-lp12:~ # ppc64_cpu --info > Core 0: 0* 1* 2* 3* 4 5 6 7 > Core 1: 8* 9* 10* 11* 12* 13* 14* 15* > > This mixed SMT level may confused end users and/or some applications. > > There is no SMT level recorded in the kernel (common code), neither > in user > space, as far as I know. Such a level is helpful when adding new CPU > or > when optimizing the energy efficiency (when reactivating CPUs). > > When SMP and HOTPLUG_SMT are defined, this series is adding a new SMT > level > (cpu_smt_num_threads) and few callbacks allowing the architecture > code to > fine control this value, setting a max and a "at boot" level, and > controling whether a thread should be onlined or not. > > v3: > Fix a build error in the patch 6/9 > v2: > As Thomas suggested, > Reword some commit's description > Remove topology_smt_supported() > Remove topology_smt_threads_supported() > Introduce CONFIG_SMT_NUM_THREADS_DYNAMIC > Remove switch() in __store_smt_control() > Update kernel-parameters.txt > > [1] > https://lore.kernel.org/linuxppc-dev/20230524155630.794584-1-mpe@ellerman.id.au/ > [2] > https://lore.kernel.org/linuxppc-dev/20230331153905.31698-1-ldufour@linux.ibm.com/ > > Laurent Dufour (1): > cpu/SMT: Remove topology_smt_supported() > > Michael Ellerman (8): > cpu/SMT: Move SMT prototypes into cpu_smt.h > cpu/SMT: Move smt/control simple exit cases earlier > cpu/SMT: Store the current/max number of threads > cpu/SMT: Create topology_smt_thread_allowed() > cpu/SMT: Allow enabling partial SMT states via sysfs > powerpc/pseries: Initialise CPU hotplug callbacks earlier > powerpc: Add HOTPLUG_SMT support > powerpc/pseries: Honour current SMT state when DLPAR onlining CPUs > > .../ABI/testing/sysfs-devices-system-cpu | 1 + > .../admin-guide/kernel-parameters.txt | 4 +- > arch/Kconfig | 3 + > arch/powerpc/Kconfig | 2 + > arch/powerpc/include/asm/topology.h | 15 +++ > arch/powerpc/kernel/smp.c | 8 +- > arch/powerpc/platforms/pseries/hotplug-cpu.c | 30 +++-- > arch/powerpc/platforms/pseries/pseries.h | 2 + > arch/powerpc/platforms/pseries/setup.c | 2 + > arch/x86/include/asm/topology.h | 4 +- > arch/x86/kernel/cpu/bugs.c | 3 +- > arch/x86/kernel/smpboot.c | 8 -- > include/linux/cpu.h | 25 +--- > include/linux/cpu_smt.h | 33 +++++ > kernel/cpu.c | 118 ++++++++++++++-- > -- > 15 files changed, 187 insertions(+), 71 deletions(-) > create mode 100644 include/linux/cpu_smt.h >
Le 05/07/2023 à 05:04, Zhang, Rui a écrit : > Hi, Laurent, > > I want to test this patch set and found that it does not apply on top > of latest usptream git, because of some changes in this merge window, > so better rebase. Hi Rui, Thanks for your interest for this series. The latest Thomas's changes came into the PowerPC next branch. I'm working on a rebase. Cheers, Laurent. > thanks, > rui > > On Thu, 2023-06-29 at 16:31 +0200, Laurent Dufour wrote: >> I'm taking over the series Michael sent previously [1] which is >> smartly >> reviewing the initial series I sent [2]. This series is addressing >> the >> comments sent by Thomas and me on the Michael's one. >> >> Here is a short introduction to the issue this series is addressing: >> >> When a new CPU is added, the kernel is activating all its threads. >> This >> leads to weird, but functional, result when adding CPU on a SMT 4 >> system >> for instance. >> >> Here the newly added CPU 1 has 8 threads while the other one has 4 >> threads >> active (system has been booted with the 'smt-enabled=4' kernel >> option): >> >> ltcden3-lp12:~ # ppc64_cpu --info >> Core 0: 0* 1* 2* 3* 4 5 6 7 >> Core 1: 8* 9* 10* 11* 12* 13* 14* 15* >> >> This mixed SMT level may confused end users and/or some applications. >> >> There is no SMT level recorded in the kernel (common code), neither >> in user >> space, as far as I know. Such a level is helpful when adding new CPU >> or >> when optimizing the energy efficiency (when reactivating CPUs). >> >> When SMP and HOTPLUG_SMT are defined, this series is adding a new SMT >> level >> (cpu_smt_num_threads) and few callbacks allowing the architecture >> code to >> fine control this value, setting a max and a "at boot" level, and >> controling whether a thread should be onlined or not. >> >> v3: >> Fix a build error in the patch 6/9 >> v2: >> As Thomas suggested, >> Reword some commit's description >> Remove topology_smt_supported() >> Remove topology_smt_threads_supported() >> Introduce CONFIG_SMT_NUM_THREADS_DYNAMIC >> Remove switch() in __store_smt_control() >> Update kernel-parameters.txt >> >> [1] >> https://lore.kernel.org/linuxppc-dev/20230524155630.794584-1-mpe@ellerman.id.au/ >> [2] >> https://lore.kernel.org/linuxppc-dev/20230331153905.31698-1-ldufour@linux.ibm.com/ >> >> Laurent Dufour (1): >> cpu/SMT: Remove topology_smt_supported() >> >> Michael Ellerman (8): >> cpu/SMT: Move SMT prototypes into cpu_smt.h >> cpu/SMT: Move smt/control simple exit cases earlier >> cpu/SMT: Store the current/max number of threads >> cpu/SMT: Create topology_smt_thread_allowed() >> cpu/SMT: Allow enabling partial SMT states via sysfs >> powerpc/pseries: Initialise CPU hotplug callbacks earlier >> powerpc: Add HOTPLUG_SMT support >> powerpc/pseries: Honour current SMT state when DLPAR onlining CPUs >> >> .../ABI/testing/sysfs-devices-system-cpu | 1 + >> .../admin-guide/kernel-parameters.txt | 4 +- >> arch/Kconfig | 3 + >> arch/powerpc/Kconfig | 2 + >> arch/powerpc/include/asm/topology.h | 15 +++ >> arch/powerpc/kernel/smp.c | 8 +- >> arch/powerpc/platforms/pseries/hotplug-cpu.c | 30 +++-- >> arch/powerpc/platforms/pseries/pseries.h | 2 + >> arch/powerpc/platforms/pseries/setup.c | 2 + >> arch/x86/include/asm/topology.h | 4 +- >> arch/x86/kernel/cpu/bugs.c | 3 +- >> arch/x86/kernel/smpboot.c | 8 -- >> include/linux/cpu.h | 25 +--- >> include/linux/cpu_smt.h | 33 +++++ >> kernel/cpu.c | 118 ++++++++++++++-- >> -- >> 15 files changed, 187 insertions(+), 71 deletions(-) >> create mode 100644 include/linux/cpu_smt.h >> >
I'm taking over the series Michael sent previously [1] which is smartly reviewing the initial series I sent [2]. This series is addressing the comments sent by Thomas and me on the Michael's one. Here is a short introduction to the issue this series is addressing: When a new CPU is added, the kernel is activating all its threads. This leads to weird, but functional, result when adding CPU on a SMT 4 system for instance. Here the newly added CPU 1 has 8 threads while the other one has 4 threads active (system has been booted with the 'smt-enabled=4' kernel option): ltcden3-lp12:~ # ppc64_cpu --info Core 0: 0* 1* 2* 3* 4 5 6 7 Core 1: 8* 9* 10* 11* 12* 13* 14* 15* This mixed SMT level may confused end users and/or some applications. There is no SMT level recorded in the kernel (common code), neither in user space, as far as I know. Such a level is helpful when adding new CPU or when optimizing the energy efficiency (when reactivating CPUs). When SMP and HOTPLUG_SMT are defined, this series is adding a new SMT level (cpu_smt_num_threads) and few callbacks allowing the architecture code to fine control this value, setting a max and a "at boot" level, and controling whether a thread should be onlined or not. v3: Fix a build error in the patch 6/9 v2: As Thomas suggested, Reword some commit's description Remove topology_smt_supported() Remove topology_smt_threads_supported() Introduce CONFIG_SMT_NUM_THREADS_DYNAMIC Remove switch() in __store_smt_control() Update kernel-parameters.txt [1] https://lore.kernel.org/linuxppc-dev/20230524155630.794584-1-mpe@ellerman.id.au/ [2] https://lore.kernel.org/linuxppc-dev/20230331153905.31698-1-ldufour@linux.ibm.com/ Laurent Dufour (1): cpu/SMT: Remove topology_smt_supported() Michael Ellerman (8): cpu/SMT: Move SMT prototypes into cpu_smt.h cpu/SMT: Move smt/control simple exit cases earlier cpu/SMT: Store the current/max number of threads cpu/SMT: Create topology_smt_thread_allowed() cpu/SMT: Allow enabling partial SMT states via sysfs powerpc/pseries: Initialise CPU hotplug callbacks earlier powerpc: Add HOTPLUG_SMT support powerpc/pseries: Honour current SMT state when DLPAR onlining CPUs .../ABI/testing/sysfs-devices-system-cpu | 1 + .../admin-guide/kernel-parameters.txt | 4 +- arch/Kconfig | 3 + arch/powerpc/Kconfig | 2 + arch/powerpc/include/asm/topology.h | 15 +++ arch/powerpc/kernel/smp.c | 8 +- arch/powerpc/platforms/pseries/hotplug-cpu.c | 30 +++-- arch/powerpc/platforms/pseries/pseries.h | 2 + arch/powerpc/platforms/pseries/setup.c | 2 + arch/x86/include/asm/topology.h | 4 +- arch/x86/kernel/cpu/bugs.c | 3 +- arch/x86/kernel/smpboot.c | 8 -- include/linux/cpu.h | 25 +--- include/linux/cpu_smt.h | 33 +++++ kernel/cpu.c | 118 ++++++++++++++---- 15 files changed, 187 insertions(+), 71 deletions(-) create mode 100644 include/linux/cpu_smt.h