From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 647ECC433EF for ; Fri, 11 Feb 2022 03:22:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:In-Reply-To:References: Message-ID:Date:Subject:CC:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=NN7ERKGcrsol5KJ03QEmwI+okN6c0GIhvu2LX/X8YpY=; b=imzkVe5snUozDR vZnViUm12v8gxhb7M9ynPToVEav2+GvQypcOKw9O7kpcLpWEFVjXE0OUjM46ukdlxfw2SsknM0O64 LDSehlIM47jOb0V8sG1XjV8y2pi9R+oybQDri8EyI0w9I7cDKcr05zb9OSMwqFVFC6IAQDY8TBxK7 gPdb1LC336kl6tzqhzGL4Mczd2E2N9N7+CKukxV6ARIBhgR0B5jV8HpF8rC8XnMabQUJ3qB9qwr4K jv3JAaaoaJe6Zg/HakrRX1WMdZQu8cp6QVDEK3IsIM+EK6cm8qG1Ku+vxIF2sY2CseBU60Yg6MNbJ trnkk9OGxCBrPZgz4uiQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nIMUd-005Zvy-Ea; Fri, 11 Feb 2022 03:21:07 +0000 Received: from szxga08-in.huawei.com ([45.249.212.255]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nIMUZ-005Ztz-Lz for linux-arm-kernel@lists.infradead.org; Fri, 11 Feb 2022 03:21:06 +0000 Received: from kwepemi100018.china.huawei.com (unknown [172.30.72.57]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4JvzKw6k2sz1FCWt; Fri, 11 Feb 2022 11:16:36 +0800 (CST) Received: from kwepemm600016.china.huawei.com (7.193.23.20) by kwepemi100018.china.huawei.com (7.221.188.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Fri, 11 Feb 2022 11:20:51 +0800 Received: from kwepemm600014.china.huawei.com (7.193.23.54) by kwepemm600016.china.huawei.com (7.193.23.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Fri, 11 Feb 2022 11:20:51 +0800 Received: from kwepemm600014.china.huawei.com ([7.193.23.54]) by kwepemm600014.china.huawei.com ([7.193.23.54]) with mapi id 15.01.2308.021; Fri, 11 Feb 2022 11:20:51 +0800 From: "Song Bao Hua (Barry Song)" To: Darren Hart , LKML , Linux Arm CC: Catalin Marinas , Will Deacon , Peter Zijlstra , Vincent Guittot , Valentin Schneider , "D . Scott Phillips" , Ilkka Koskinen , "stable@vger.kernel.org" Subject: RE: [PATCH] arm64: smp: Skip MC domain for SoCs without shared cache Thread-Topic: [PATCH] arm64: smp: Skip MC domain for SoCs without shared cache Thread-Index: AQHYHujOa/yZ8dQpvUyNjGL3bOgZ+KyNrJkA Date: Fri, 11 Feb 2022 03:20:51 +0000 Message-ID: References: <8c4a69eca4d0591f30c112df59c5098c24923bd3.1644543449.git.darren@os.amperecomputing.com> In-Reply-To: <8c4a69eca4d0591f30c112df59c5098c24923bd3.1644543449.git.darren@os.amperecomputing.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.126.200.29] MIME-Version: 1.0 X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220210_192104_180994_17D7C119 X-CRM114-Status: GOOD ( 24.37 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org > -----Original Message----- > From: Darren Hart [mailto:darren@os.amperecomputing.com] > Sent: Friday, February 11, 2022 2:43 PM > To: LKML ; Linux Arm > > Cc: Catalin Marinas ; Will Deacon ; > Peter Zijlstra ; Vincent Guittot > ; Song Bao Hua (Barry Song) > ; Valentin Schneider > ; D . Scott Phillips > ; Ilkka Koskinen > ; stable@vger.kernel.org > Subject: [PATCH] arm64: smp: Skip MC domain for SoCs without shared cache > > SoCs such as the Ampere Altra define clusters but have no shared > processor-side cache. As of v5.16 with CONFIG_SCHED_CLUSTER and > CONFIG_SCHED_MC, build_sched_domain() will BUG() with: > > BUG: arch topology borken > the CLS domain not a subset of the MC domain > > for each CPU (160 times for a 2 socket 80 core Altra system). The MC > level cpu mask is then extended to that of the CLS child, and is later > removed entirely as redundant. > > This change detects when all cpu_coregroup_mask weights=1 and uses an > alternative sched_domain_topology equivalent to the default if > CONFIG_SCHED_MC were disabled. > > The final resulting sched domain topology is unchanged with or without > CONFIG_SCHED_CLUSTER, and the BUG is avoided: > > For CPU0: > > With CLS: > CLS [0-1] > DIE [0-79] > NUMA [0-159] > > Without CLS: > DIE [0-79] > NUMA [0-159] > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Peter Zijlstra > Cc: Vincent Guittot > Cc: Barry Song > Cc: Valentin Schneider > Cc: D. Scott Phillips > Cc: Ilkka Koskinen > Cc: # 5.16.x > Signed-off-by: Darren Hart Hi Darrent, What kind of resources are clusters sharing on Ampere Altra? So on Altra, cpus are not sharing LLC? Each LLC is separate for each cpu? > --- > arch/arm64/kernel/smp.c | 32 ++++++++++++++++++++++++++++++++ > 1 file changed, 32 insertions(+) > > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c > index 27df5c1e6baa..0a78ac5c8830 100644 > --- a/arch/arm64/kernel/smp.c > +++ b/arch/arm64/kernel/smp.c > @@ -715,9 +715,22 @@ void __init smp_init_cpus(void) > } > } > > +static struct sched_domain_topology_level arm64_no_mc_topology[] = { > +#ifdef CONFIG_SCHED_SMT > + { cpu_smt_mask, cpu_smt_flags, SD_INIT_NAME(SMT) }, > +#endif > + > +#ifdef CONFIG_SCHED_CLUSTER > + { cpu_clustergroup_mask, cpu_cluster_flags, SD_INIT_NAME(CLS) }, > +#endif > + { cpu_cpu_mask, SD_INIT_NAME(DIE) }, > + { NULL, }, > +}; > + > void __init smp_prepare_cpus(unsigned int max_cpus) > { > const struct cpu_operations *ops; > + bool use_no_mc_topology = true; > int err; > unsigned int cpu; > unsigned int this_cpu; > @@ -758,6 +771,25 @@ void __init smp_prepare_cpus(unsigned int max_cpus) > > set_cpu_present(cpu, true); > numa_store_cpu_info(cpu); > + > + /* > + * Only use no_mc topology if all cpu_coregroup_mask weights=1 > + */ > + if (cpumask_weight(cpu_coregroup_mask(cpu)) > 1) > + use_no_mc_topology = false; This seems to be wrong? If you have 5 cpus, Cpu0 has cpu_coregroup_mask(cpu)== 1, cpu1-4 has cpu_coregroup_mask(cpu)== 4, for cpu0, you still need to remove MC, but for cpu1-4, you will need CLS and MC both? This flag shouldn't be global. > + } > + > + /* > + * SoCs with no shared processor-side cache will have cpu_coregroup_mask > + * weights=1. If they also define clusters with cpu_clustergroup_mask > + * weights > 1, build_sched_domain() will trigger a BUG as the CLS > + * cpu_mask will not be a subset of MC. It will extend the MC cpu_mask > + * to match CLS, and later discard the MC level. Avoid the bug by using > + * a topology without the MC if the cpu_coregroup_mask weights=1. > + */ > + if (use_no_mc_topology) { > + pr_info("cpu_coregroup_mask weights=1, skipping MC topology level"); > + set_sched_topology(arm64_no_mc_topology); > } > } > > -- > 2.31.1 Thanks Barry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel