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;
Date:   Fri, 11 Feb 2022 09:54:39 -0800
From:   Darren Hart <darren@os.amperecomputing.com>
To:     "Song Bao Hua (Barry Song)" <song.bao.hua@hisilicon.com>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Linux Arm <linux-arm-kernel@lists.infradead.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Valentin Schneider <valentin.schneider@arm.com>,
        "D . Scott Phillips" <scott@os.amperecomputing.com>,
        Ilkka Koskinen <ilkka@os.amperecomputing.com>,
        "stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH] arm64: smp: Skip MC domain for SoCs without shared cache
Message-ID: <Ygai330kyA1yYgj/@fedora>
References: <8c4a69eca4d0591f30c112df59c5098c24923bd3.1644543449.git.darren@os.amperecomputing.com>
 <ec9be4eb7a0548178191edd51ddd309f@hisilicon.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ec9be4eb7a0548178191edd51ddd309f@hisilicon.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?lAdFbnJlPqWs16sVvDt8nz+0FnmCJFnqCJftzNJ3agMWSvkZVkkugS748yJB?=
 =?us-ascii?Q?HpIUz5huanNYTUSawrh72cYBwtGQQor3KuLX31UV8OFRN5hUscg6n7os8v2z?=
 =?us-ascii?Q?jFTC7R6I70Xqn9E2lZeDTscPjmwQZvuFVNNpcu8OV6fw2LeeejFPn5/W2FuB?=
 =?us-ascii?Q?ytcW5nZWGcg82MvuzECzR75cugYw4Ss9EVDsD/jl7f7huvJNEkx3M6xzTnoF?=
 =?us-ascii?Q?L6xsnt0pHTBALg4LOA9IB5ddGoeIAByMVN2fc6X+VypgcczIcsPye4TrFDzG?=
 =?us-ascii?Q?y4iDU/9zsgpMcPbrLeSk/YG6WbbAQ41VrvV8bmxWOOnV64w4Cy0ZAwXA1qlq?=
 =?us-ascii?Q?REogbcejJH/33mtEgCwyrqk1Iil1MDEF0hZXAfu3JaVXK7OveURdNR0kk7IS?=
 =?us-ascii?Q?faufabMOB2Hb6naJEdLs1lBUCbAPgKiberzzu4BoloR0pcKNvmgTcJwKIEXx?=
 =?us-ascii?Q?Cp6kNl13CTbLN1eRPUBNw5feiidFg3VSsL/ZVqMN6vgaLrYixY63MK1hK5Sz?=
 =?us-ascii?Q?BUsq/rVnbGNKfcNZ0Pq4COC4hi22/PXog5vSZ3trp/X2C6gWEcoKfILbPIvD?=
 =?us-ascii?Q?mJ+cY3ZuTnU1X4q8IW7ASmAvOqJ5uZA/z+K9KnL+V5D6PvHVdPNszOIRhdnq?=
 =?us-ascii?Q?tD8AIbiEBHiwjV8lnBJskpqpHQac+vrUEfDGtdRq6ckuHhIwpxWPJZgBDuLH?=
 =?us-ascii?Q?gFRdZocJngwt0LPFKaKJbUL8KrKbFk09P13ae9wNBRZKifqIthB2FFTyb7Sp?=
 =?us-ascii?Q?kkgOciaGjooGQKbcr0bmTLBslJ52fbX3FRsvLiohnbrjstUIThkbK11z2/UF?=
 =?us-ascii?Q?JkIh8IBUdUDMkOHOq28hL2/JhZ4bsphmy/8tcKclIgkEGmc4VZecR1UdoQcR?=
 =?us-ascii?Q?5LWM69+35qoB3MFww2EhENkg3b/WOJJLvuKTJQgIaP5wFCfvllpyf2o84b1x?=
 =?us-ascii?Q?dPogSKSyq0yl4BfFkyiKJN5VMwmEoFyBcGdNLmAOnKCKWyOux3HU3sM0sHtY?=
 =?us-ascii?Q?KmL6swg/20TvHbhKGCsqeSKQyd7zIwf4a6rDoQgmgh0UGpI0DoK+iCkqT+Qc?=
 =?us-ascii?Q?Ns8kvlM43wASZx/UXluruGgGEiSsuBrx5gyOi3iXurf7RNZNA8kQeSed5nOB?=
 =?us-ascii?Q?8M3TIUZ7F9p1M9rM7ywFjeMV5/FiIHaG/U2S0cWatpbbhJd+3ONLR4RJOULp?=
 =?us-ascii?Q?/+61pWa+z6X5jDjL/14ANW4+YVZreLXrEj0kONGx5Ruur5ZlfgzryONL4gWm?=
 =?us-ascii?Q?+o4J2TYV9SLscktDHaqcJ2V84rUCB15FOUL227u5Sk58FkB3T3gwTK6+J8Ta?=
 =?us-ascii?Q?jgHS0qrci39nHCrx3awuomw6XBXQDn8WCNJcVLkFMbK7AUbXUem4sqHTlpW7?=
 =?us-ascii?Q?T8VbzrcM82im8W+8x9Cy9QeRC++X4eUpd2LFM2tw2Y2Opk1dO3G2YGObTht5?=
 =?us-ascii?Q?tRUFhgk3V5KYh1MHZHF4OBo2/gXs4MwtgLdzSQ/aPM2T2cifRHnQqRLHIml/?=
 =?us-ascii?Q?1o7fWGCVZfJSjJr4tgFDuCqKpW3u+/7Qp7GTr4q0I6IMwt5luIjRg/Q3oP9s?=
 =?us-ascii?Q?ezcoog2xkU+xFXpajiuawat/7mKHGbIJrPoeDkosvizg0usN+r9hGPmBI+pv?=
 =?us-ascii?Q?wO0V3/ARySXR30d7jENFkOK/8RFftZlikSVtKc3RaUoR7fqcuIG72YIbndVl?=
 =?us-ascii?Q?nOPtwEBuYBHaheWeq5oJ90WJuBtEDg52akhL7d2tUytZYkNp67LGtg3r4bv0?=
 =?us-ascii?Q?xwgooOQdJg=3D=3D?=
X-OriginatorOrg: os.amperecomputing.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2b9ee30b-c38b-42bd-ad3e-08d9ed8793fc
X-MS-Exchange-CrossTenant-AuthSource: SA0PR01MB6329.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Feb 2022 17:54:41.2094
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3bc2b170-fd94-476d-b0ce-4229bdc904a7
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: y9YTjhPkk6Q2H1dtTMt9O/vKD7RP5RooCK3G4xMo8MUN14uo4rETfDhLV42WZvDlIHAjRL8KEsvhEM8U+hhPWDMt1yv7N47Kw0kDWDyJmz1+l/4bm1b4qSFPrGNMirTW
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR01MB4836
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,
        SPF_HELO_PASS,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

On Fri, Feb 11, 2022 at 03:20:51AM +0000, Song Bao Hua (Barry Song) wrote:
> 
> 
> > -----Original Message-----
> > From: Darren Hart [mailto:darren@os.amperecomputing.com]
> > Sent: Friday, February 11, 2022 2:43 PM
> > To: LKML <linux-kernel@vger.kernel.org>; Linux Arm
> > <linux-arm-kernel@lists.infradead.org>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>; Will Deacon <will@kernel.org>;
> > Peter Zijlstra <peterz@infradead.org>; Vincent Guittot
> > <vincent.guittot@linaro.org>; Song Bao Hua (Barry Song)
> > <song.bao.hua@hisilicon.com>; Valentin Schneider
> > <valentin.schneider@arm.com>; D . Scott Phillips
> > <scott@os.amperecomputing.com>; Ilkka Koskinen
> > <ilkka@os.amperecomputing.com>; 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 <catalin.marinas@arm.com>
> > Cc: Will Deacon <will@kernel.org>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Vincent Guittot <vincent.guittot@linaro.org>
> > Cc: Barry Song <song.bao.hua@hisilicon.com>
> > Cc: Valentin Schneider <valentin.schneider@arm.com>
> > Cc: D. Scott Phillips <scott@os.amperecomputing.com>
> > Cc: Ilkka Koskinen <ilkka@os.amperecomputing.com>
> > Cc: <stable@vger.kernel.org> # 5.16.x
> > Signed-off-by: Darren Hart <darren@os.amperecomputing.com>
> 
> Hi Darrent,

Hi Barry, thanks for the review.

> What kind of resources are clusters sharing on Ampere Altra?

The cluster pairs are DSU pairs (ARM DynamIQ Shared Unit). While there
is no shared L3 cache, they do share an SCU (snoop control unit) and
have a cache coherency latency advantage relative to non-DSU pairs.

The Anandtech Altra review illustrates this advantage:
https://www.anandtech.com/show/16315/the-ampere-altra-review/3

Notably, the SCHED_CLUSTER change did result in marked improvements for
some interactive workloads.

> So on Altra, cpus are not sharing LLC? Each LLC is separate
> for each cpu?

Correct. On the processor side the last level is at each cpu, and then
there is a memory side SLC (system level cache) that is shared by all
cpus.

> 
> > ---
> >  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.

Please note that this patch is intended to maintain an identical final
sched domain construction for a symmetric topology with no shared
processor-side cache and with cache advantaged clusters and avoid the
BUG messages since this topology is correct for this architecture.

By using a sched topology without the MC layer, this more accurately
describes this architecture and does not require changes to
build_sched_domain(), in particular changes to the assumptions about
what a valid topology is.

The test above tests every cpu coregroup weight in order to limit the
impact of this change to this specific kind of topology. It
intentionally does not address, nor change existing behavior for, the
assymetrical topology you describe.

I felt this was the less invasive approach and consistent with how other
architectures handled "non-default" topologies.

If there is interest on working toward a more generic topology builder,
I'd be interested in working on that too, but I think this change makes
sense in the near term.

Thanks,

> 
> > +	}
> > +
> > +	/*
> > +	 * 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
> 

-- 
Darren Hart
Ampere Computing / OS and Kernel