Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp82712pxb; Tue, 5 Apr 2022 00:47:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyl9NeMtsCElBtBQw3iDRq7+U2PNugCJcRTnDQL32hpBZvaCGcUeH/t+YMHT4xZjI2LFFC0 X-Received: by 2002:aa7:d495:0:b0:41c:c46a:550f with SMTP id b21-20020aa7d495000000b0041cc46a550fmr2181798edr.305.1649144846277; Tue, 05 Apr 2022 00:47:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649144846; cv=none; d=google.com; s=arc-20160816; b=sHbvOqKKNmK1IGLWo+7UIjQFLsoBWTM/VBmWY5dGqfmw4Z7F9d+STgW9cGP2SPUbMe OijV/HK4ISCTYdkm9aIk2DKr+KOIavKRaN2zlT4BuiCC/CnLcJ8M6QCagjp3e1ATUmb+ 7FOgc3ee3Vcug7iwWzK0q077gWRVKCDRy/qSWOIA/1drKoelxjAadyN/ggWrHSXK6YJH jK0VwQmnOvQMPL0sPKLobdEtKJp9L7FNnPPzQPfwIGZvROREhF5NliauHsE+2LajeT5A t28bgY1qeJYggEmRQucyPdzTXWymqD63Wvlmx5ITKFRs5oWrV7q5mRBAA6eiz+WNBEd0 rI3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=CTVwwGfd5gW6dvOyGN6tILqjhocBpp2BuslCi0M2GwY=; b=m0Qla7ywuWq5G7MTPpSPwApGvrRsnwiBYJi6CTxRx8/nPxk6kIaeyBUAjvrH58Y+yL ZAI+KzveJQMJ3s9xbXp2teChDAiYoya266gmn3WUvWIi0pFZO4RDDFILnPV+WltWevQ3 DAL4ppdz8plMtkQxw95Qx9+9v3ag3oDlUgjYmwgs1UT7TNGo0cURSk0vPowmpXygdjNd bjQdWhVqlEf8R735hfwn1PND/PyM9DJYlbYgOlpyMUaVMr0U2EzaOQ9igYj4lTltW3Cs dUByug+olWs/BXKmXlYgZtMzk2NfuvprvOR10dhppaNnlGrxezPskukb5CYTw54736BZ xn4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=atgAr+Nv; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j11-20020a509d4b000000b00418c2b5be7csi8524192edk.350.2022.04.05.00.47.00; Tue, 05 Apr 2022 00:47:26 -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=@gmail.com header.s=20210112 header.b=atgAr+Nv; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230360AbiDEGkQ (ORCPT + 99 others); Tue, 5 Apr 2022 02:40:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33450 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230075AbiDEGkN (ORCPT ); Tue, 5 Apr 2022 02:40:13 -0400 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 62C162A262; Mon, 4 Apr 2022 23:38:15 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id qh7so14520616ejb.11; Mon, 04 Apr 2022 23:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CTVwwGfd5gW6dvOyGN6tILqjhocBpp2BuslCi0M2GwY=; b=atgAr+NvO47dcsXz5odpuvNPIxhtUuBhGr9Dk/HgOQqiT4HkVoeDyghKPEiamYbNKf VPQmEvbRNFflwRDbi0jROxf7ZyxWDG61lVbZvP4o++SlVCmTkCkU3X2NavRE2tCwCgcn QKNLUgrEa3t7Zb0GNEYxuhmA6LnkY98tycchLYO/gvc8PbPuB5djiVj0XBruf1m/IbH4 +EEDZ+7K2s95IsJBVQFizE6kvgoX2vtvZOKUR6MjF/t1r1P3XNmTe6rN68IAjXwpo99Z 5V79OkiHxvxXX+Z8eSi9pCBv/XK2kgxg2HJ23w9t51anj4uV3cXcmS1wSBzQ9Rs79/ul 6Skg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CTVwwGfd5gW6dvOyGN6tILqjhocBpp2BuslCi0M2GwY=; b=5sj1fruTF1wdV32Lz8IdqlUETgjVMwe2n0H0BKC6F7Z2d42K/qVizpW/ZRfwXNWRVV Ifw+dEyvDaKfA0MBmAipkGyM5JP45GTHuIrzJzbQA/A6IvqNq95kZd/AShr8aFLvdWW5 ffFDL4aZE8YteRaQIC6QFPaNdv0onDFlC8f5s6jzgjT4eOTCKZNDbgFB63S3JlMb9D8c 5ToEmUnsPoEQ4vHSMaHXwIDpvcfQMdzmrC1dGdD3Y0BODNlDnzvUhZS428fG9GkhURk9 S8PS/5EYQk4EoNP0sB/bzgqCaYUYTzJNYYc1Tn6RL5mqPyxFZLffXZz3eR3W1BdtYtgz GoPA== X-Gm-Message-State: AOAM530hZ7AnWC7+MPMZHOQO0G0RBslkOT3mpFM7bQ+EuDgWUyLWlR+D WYpVCMW7miobnXDp4yJdO2sNhRNeTO6SPKcGC+g= X-Received: by 2002:a17:906:2991:b0:6cd:ac19:ce34 with SMTP id x17-20020a170906299100b006cdac19ce34mr1986937eje.746.1649140693847; Mon, 04 Apr 2022 23:38:13 -0700 (PDT) MIME-Version: 1.0 References: <3d58dc946a4fa1cc696d05baad1cf05ae686a86d.1649115057.git.darren@os.amperecomputing.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Tue, 5 Apr 2022 18:38:01 +1200 Message-ID: Subject: Re: [PATCH v4] topology: make core_mask include at least cluster_siblings To: Darren Hart Cc: LKML , Linux Arm , Greg Kroah-Hartman , Sudeep Holla , "Rafael J. Wysocki" , Catalin Marinas , Will Deacon , Peter Zijlstra , Vincent Guittot , Barry Song , Valentin Schneider , "D . Scott Phillips" , Ilkka Koskinen , Carl Worth , stable@vger.kernel.org, Dietmar Eggemann Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,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: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 5, 2022 at 3:46 PM Darren Hart wrote: > > On Mon, Apr 04, 2022 at 04:40:37PM -0700, Darren Hart wrote: > > Ampere Altra defines CPU clusters in the ACPI PPTT. They share a Snoop > > Control Unit, but have no shared CPU-side last level cache. > > > > cpu_coregroup_mask() will return a cpumask with weight 1, while > > cpu_clustergroup_mask() will return a cpumask with weight 2. > > > > As a result, build_sched_domain() will BUG() once per CPU with: > > > > BUG: arch topology borken > > the CLS domain not a subset of the MC domain > > > > The MC level cpumask is then extended to that of the CLS child, and is > > later removed entirely as redundant. This sched domain topology is an > > improvement over previous topologies, or those built without > > SCHED_CLUSTER, particularly for certain latency sensitive workloads. > > With the current scheduler model and heuristics, this is a desirable > > default topology for Ampere Altra and Altra Max system. > > > > Rather than create a custom sched domains topology structure and > > introduce new logic in arch/arm64 to detect these systems, update the > > core_mask so coregroup is never a subset of clustergroup, extending it > > to cluster_siblings if necessary. Only do this if CONFIG_SCHED_CLUSTER > > is enabled to avoid also changing the topology (MC) when > > CONFIG_SCHED_CLUSTER is disabled. > > > > This has the added benefit over a custom topology of working for both > > symmetric and asymmetric topologies. It does not address systems where > > the CLUSTER topology is above a populated MC topology, but these are not > > considered today and can be addressed separately if and when they > > appear. > > > > The final sched domain topology for a 2 socket Ampere Altra system is > > unchanged with or without CONFIG_SCHED_CLUSTER, and the BUG is avoided: > > > > For CPU0: > > > > CONFIG_SCHED_CLUSTER=y > > CLS [0-1] > > DIE [0-79] > > NUMA [0-159] > > > > CONFIG_SCHED_CLUSTER is not set > > DIE [0-79] > > NUMA [0-159] > > > > Cc: Greg Kroah-Hartman > > Cc: Sudeep Holla > > Cc: "Rafael J. Wysocki" > > 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: Carl Worth > > Cc: # 5.16.x > > Suggested-by: Barry Song > > Signed-off-by: Darren Hart > > --- > > v1: Drop MC level if coregroup weight == 1 > > v2: New sd topo in arch/arm64/kernel/smp.c > > v3: No new topo, extend core_mask to cluster_siblings > > v4: Rebase on 5.18-rc1 for GregKH to pull. Add IS_ENABLED(CONFIG_SCHED_CLUSTER). > > A bit more context on the state of review: > > Several folks reviewed, but I didn't add their Reviewed-by since I added the > IS_ENABLED(CONFIG_SCHED_CLUSTER) test since they reviewed it last. This change > preserves the stated intent of the change when CONFIG_SCHED_CLUSTER is disabled. Everything still works even without IS_ENABLED(CONFIG_SCHED_CLUSTER), right? Anyway, putting IS_ENABLED(CONFIG_SCHED_CLUSTER) seems to be right as well. But it seems it is still a good choice to put all these reviewed-by and acked-by you got in v3? I don't think the added IS_ENABLED will change their decisions. > > Barry Song - Suggested this approach > Vincent Guittot - informal review with reservations > Sudeep Holla - Acked-by > Dietmar Eggemann - informal review (added to Cc, apologies for the omission Dietmar) > > All but Barry's recommendation captured in the v3 thread: > https://lore.kernel.org/linux-arm-kernel/f1deaeabfd31fdf512ff6502f38186ef842c2b1f.1646413117.git.darren@os.amperecomputing.com/ > > Thanks, > > > > > drivers/base/arch_topology.c | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c > > index 1d6636ebaac5..5497c5ab7318 100644 > > --- a/drivers/base/arch_topology.c > > +++ b/drivers/base/arch_topology.c > > @@ -667,6 +667,15 @@ const struct cpumask *cpu_coregroup_mask(int cpu) > > core_mask = &cpu_topology[cpu].llc_sibling; > > } > > > > + /* > > + * For systems with no shared cpu-side LLC but with clusters defined, > > + * extend core_mask to cluster_siblings. The sched domain builder will > > + * then remove MC as redundant with CLS if SCHED_CLUSTER is enabled. > > + */ > > + if (IS_ENABLED(CONFIG_SCHED_CLUSTER) && > > + cpumask_subset(core_mask, &cpu_topology[cpu].cluster_sibling)) > > + core_mask = &cpu_topology[cpu].cluster_sibling; > > + > > return core_mask; > > } > > > -- > Darren Hart > Ampere Computing / OS and Kernel Thanks Barry