Message ID | 20231121092602.47792-1-yangyicong@huawei.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2b07:b0:403:3b70:6f57 with SMTP id io7csp499977vqb; Tue, 21 Nov 2023 01:29:55 -0800 (PST) X-Google-Smtp-Source: AGHT+IEH1z6umQsw2xnyUghRBsAVju8GK8skJ7se59Yx0K4dvoyiulLvP2mlorPy+YRvEm6T9wsh X-Received: by 2002:a05:6830:44a4:b0:6d6:4f51:1e3e with SMTP id r36-20020a05683044a400b006d64f511e3emr12758532otv.25.1700558995534; Tue, 21 Nov 2023 01:29:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700558995; cv=none; d=google.com; s=arc-20160816; b=hluvShnLDVMwn57AYeinYAqYUXmCYTTiHH3RhI9e3J20VC/7Si/9zqf6dERH+vBHfy Sm08lDTuDO8B7P54LIVJK2x4Cr+4TeNcbkiW4sx8u1SBhhF05YZRb5xYcgn+epJpDsm6 dp4a5uhzG8JHschvqmMMAUEjc74dmWiyvDmVVJP/6gTRVe5nksNGEfzM0TWvu/xjxuG9 BgeWbgvzRaUyKJp8HIzJBg2RwHBQ34BaP9FA+p1VGe6+4RpNus0TVAT13aOcIf8edF3t X/UmbFx0TJ5UJI8M01CBy25TK8WJfJFpB4xBQvFm0eDeqOqle2LSz3XWLzqgQSURLvvx dLhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=u05tRTrc7wi+JIrNwvr+7LfAM1C/UuMkzardZymESdQ=; fh=3iB9MPM7gOV8iaw6nlpksJFY47xoJvfTkJIkOXUlBK4=; b=ROo0CyoIyRM+64L+kG+0lXK0E+TohPLpFeRdjUft+eg8032slwPY1yWgYQoZT+2UP9 5mQYWTHd8Vy8Z0qTt4aGti3bEMgFLANgDKAPEX7Agkc1n2d5ViHyMaiGhvLcVqYDCJbL LG/ET6cnGA6gyI8IBLs0x1UnzLesif8Kqrtejc+YvsKtczlJ6I8ClqmhFigbaH9ATlFy /NX35CV8TyVyTEDcDEI/lvDEVFPq34SAmeegWob6X3dOz3N7cyYa0emAl/nIyLMIyzqt s8Jp+8VN5qp+YpyYfSZ9+bQLDi1HkZvSkVaj64znkop5fi9YX2g7uj0cxp/r4aB38ziW gdqA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from lipwig.vger.email (lipwig.vger.email. [23.128.96.33]) by mx.google.com with ESMTPS id f27-20020a63101b000000b00578da80ac3dsi10009841pgl.80.2023.11.21.01.29.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Nov 2023 01:29:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id BC86280CE7E0; Tue, 21 Nov 2023 01:29:44 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233573AbjKUJ3i (ORCPT <rfc822;ouuuleilei@gmail.com> + 99 others); Tue, 21 Nov 2023 04:29:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55802 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232229AbjKUJ3c (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 21 Nov 2023 04:29:32 -0500 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 45EEB10E for <linux-kernel@vger.kernel.org>; Tue, 21 Nov 2023 01:29:24 -0800 (PST) Received: from canpemm500009.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4SZJr05lYbzRj3v; Tue, 21 Nov 2023 17:25:04 +0800 (CST) Received: from localhost.localdomain (10.50.165.33) by canpemm500009.china.huawei.com (7.192.105.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 21 Nov 2023 17:29:19 +0800 From: Yicong Yang <yangyicong@huawei.com> To: <catalin.marinas@arm.com>, <will@kernel.org>, <sudeep.holla@arm.com>, <linux-arm-kernel@lists.infradead.org> CC: <dietmar.eggemann@arm.com>, <gregkh@linuxfoundation.org>, <rafael@kernel.org>, <jonathan.cameron@huawei.com>, <prime.zeng@hisilicon.com>, <linuxarm@huawei.com>, <yangyicong@hisilicon.com>, <linux-kernel@vger.kernel.org> Subject: [PATCH v4 0/4] Support SMT control on arm64 Date: Tue, 21 Nov 2023 17:25:58 +0800 Message-ID: <20231121092602.47792-1-yangyicong@huawei.com> X-Mailer: git-send-email 2.31.0 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.50.165.33] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To canpemm500009.china.huawei.com (7.192.105.203) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Tue, 21 Nov 2023 01:29:44 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783165349276351630 X-GMAIL-MSGID: 1783165349276351630 |
Series | Support SMT control on arm64 | |
Message
Yicong Yang
Nov. 21, 2023, 9:25 a.m. UTC
From: Yicong Yang <yangyicong@hisilicon.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@intel.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
arm64: topology: Support SMT control on ACPI based system
arm64: Kconfig: Enable HOTPLUG_SMT
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/topology.c | 23 ++++++++++++++++++
drivers/base/arch_topology.c | 45 +++++++++++++++++++++++++++++++++++
include/linux/arch_topology.h | 14 +++++++++++
4 files changed, 83 insertions(+)
Comments
Hi Sudeep, Catalin, Will and ARM folks, Any comments? Appreciate for any feedbacks. Thanks. On 2023/11/21 17:25, Yicong Yang wrote: > From: Yicong Yang <yangyicong@hisilicon.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@intel.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 > arm64: topology: Support SMT control on ACPI based system > arm64: Kconfig: Enable HOTPLUG_SMT > > arch/arm64/Kconfig | 1 + > arch/arm64/kernel/topology.c | 23 ++++++++++++++++++ > drivers/base/arch_topology.c | 45 +++++++++++++++++++++++++++++++++++ > include/linux/arch_topology.h | 14 +++++++++++ > 4 files changed, 83 insertions(+) >
On Tue, Nov 21, 2023 at 05:25:58PM +0800, Yicong Yang wrote: > From: Yicong Yang <yangyicong@hisilicon.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@intel.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. Will
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@hisilicon.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@intel.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.