Message ID | 20230629143149.79073-1-ldufour@linux.ibm.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp9695385vqr; Thu, 29 Jun 2023 07:53:37 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7zCOd2AygWF0mAbVE+iWAGhVkuhOqBjQQd342y2o7N9BJde08edtzstkaa348c8cLu7VU2 X-Received: by 2002:a05:6a20:7d99:b0:12b:bc21:65b9 with SMTP id v25-20020a056a207d9900b0012bbc2165b9mr43778pzj.0.1688050417224; Thu, 29 Jun 2023 07:53:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688050417; cv=none; d=google.com; s=arc-20160816; b=rTkWvo5MQ2aPc8F3KLIVzci/zjGvUdpP6mmZLFkmVWHkvksYAHn/lsInD4cVtikyEr NP0uprru9tQoY1dQ8bx3nzhv1LNY7f/GWcAj3Yyujd29JbSDw0RhTqEiPpTAR4S4/+Jy 9nNwrD4UsrMt5xe4Tomjpmr4filv7G1EqagA3eHWHDuHfhFu5tq4t7NJsqQ0br+ke2U+ FN1VR2+QDWOKVkPKK5G/zeCuMH3zhaPjOUIaxd6xk/c7dte5zQRy7r5MSjCWZ2geqdLI yKYMSCpsKG7D5Xnz+SEmZh+U5jm8DP5HtCCSSOP6kQwPa9jsXwAWFBrohlEv5UkDEjvS Cx9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :message-id:date:subject:cc:to:from:dkim-signature; bh=PgkKmvKoXWdV8E7x/QtCAbTgetf5V95w91yWR0QNxXU=; fh=8cYd2FlVZORVk636/TRZSjcpEkmtW92vhqoVMGOqVio=; b=qK3pF/N9d1eV+g43th9B4GrT6fGV05Wk1LPJFI9XUQI12DU79tzsrlR8Ot4z/uugSi /PvloCI+r3v2xRTWKGxlZ2XkVfXH2/Z0aNm4jmddjj4X7A/Fhw/o30xZxmAe0rMnNWm8 cYoTHVYd47YLH7rX+BsrfH4t4n64G9WuWSSq/Cvi012qxaXHLkQ6SyQAC4S7N6wegFvC n0esrryWYgA3KBTh986mf9DYreRStEtAf3btiAyNi1MJTxGMzRCLNaS85QmpN3XXcseq /ZsjfL7/LDDD19DnG97PJcp+GhQ4Onn8wcMlLSL4VX+T3wnv6jCVFNCW3rZb6ld7Iq0e X9Og== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=HC79Xd3r; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=ibm.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f30-20020a631f1e000000b00544b88dda25si10558991pgf.64.2023.06.29.07.53.24; Thu, 29 Jun 2023 07:53:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=HC79Xd3r; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232372AbjF2OcX (ORCPT <rfc822;ivan.orlov0322@gmail.com> + 99 others); Thu, 29 Jun 2023 10:32:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33638 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229936AbjF2OcS (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 29 Jun 2023 10:32:18 -0400 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 457942D69; Thu, 29 Jun 2023 07:32:16 -0700 (PDT) Received: from pps.filterd (m0360083.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 35TEMAqF030331; Thu, 29 Jun 2023 14:31:57 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : date : message-id : content-transfer-encoding : mime-version; s=pp1; bh=PgkKmvKoXWdV8E7x/QtCAbTgetf5V95w91yWR0QNxXU=; b=HC79Xd3rZ8F47qC6eNtnNILy1yBN6ApgcH1YmEimwMbh5hXNHYMr0tj8Z3Dg1ASvl/X0 Yo9BYyvzAb50msju06cQ4mJnA64HnbqWniCOuKvSMBTdwLIJzSbB2ulgxVjFRnfv0JCH N1W2m2/T+99XB08jpSIvcNFMccSfTGh5bKgntLWRnwOgquoPULO8WYoHDmqicO5NycA+ OKF/4U+SsNMJ9VZHfiibmWY7I1+K1tAcrLsDzvap+EQRfjkbKrgYGWkpae6edfQLrBsP H3JPl92u1PlvJWovoXEW+70LBjT8sjgIp4cs4Pgi2mpKU9MJXZL3yK8WhaX/x2pI3exz Yw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3rhbnf08be-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Jun 2023 14:31:57 +0000 Received: from m0360083.ppops.net (m0360083.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 35TENke0004150; Thu, 29 Jun 2023 14:31:56 GMT Received: from ppma03ams.nl.ibm.com (62.31.33a9.ip4.static.sl-reverse.com [169.51.49.98]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3rhbnf089y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Jun 2023 14:31:56 +0000 Received: from pps.filterd (ppma03ams.nl.ibm.com [127.0.0.1]) by ppma03ams.nl.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 35T4RLxX032704; Thu, 29 Jun 2023 14:31:54 GMT Received: from smtprelay02.fra02v.mail.ibm.com ([9.218.2.226]) by ppma03ams.nl.ibm.com (PPS) with ESMTPS id 3rdr453d7r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Jun 2023 14:31:53 +0000 Received: from smtpav01.fra02v.mail.ibm.com (smtpav01.fra02v.mail.ibm.com [10.20.54.100]) by smtprelay02.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 35TEVpP422741684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Jun 2023 14:31:51 GMT Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7F98620043; Thu, 29 Jun 2023 14:31:51 +0000 (GMT) Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1041A20040; Thu, 29 Jun 2023 14:31:51 +0000 (GMT) Received: from pomme.tlslab.ibm.com (unknown [9.101.4.33]) by smtpav01.fra02v.mail.ibm.com (Postfix) with ESMTP; Thu, 29 Jun 2023 14:31:50 +0000 (GMT) From: Laurent Dufour <ldufour@linux.ibm.com> To: linuxppc-dev@lists.ozlabs.org Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, mpe@ellerman.id.au, npiggin@gmail.com, christophe.leroy@csgroup.eu, tglx@linutronix.de, dave.hansen@linux.intel.com, mingo@redhat.com, bp@alien8.de Subject: [PATCH v3 0/9] Introduce SMT level and add PowerPC support Date: Thu, 29 Jun 2023 16:31:40 +0200 Message-ID: <20230629143149.79073-1-ldufour@linux.ibm.com> X-Mailer: git-send-email 2.41.0 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: KnQKqTYL1ux1N6LbZbIv59sbgWflxRND X-Proofpoint-ORIG-GUID: I0FfXe544_ewxmg6_4UIwmxfARBnRcst Content-Transfer-Encoding: 8bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-06-29_03,2023-06-27_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 adultscore=0 lowpriorityscore=0 clxscore=1015 phishscore=0 spamscore=0 bulkscore=0 mlxlogscore=999 priorityscore=1501 malwarescore=0 suspectscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2306290131 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1770049154504163369?= X-GMAIL-MSGID: =?utf-8?q?1770049154504163369?= |
Series |
Introduce SMT level and add PowerPC support
|
|
Message
Laurent Dufour
June 29, 2023, 2:31 p.m. UTC
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
Comments
> 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 >> >