Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp2083021iob; Fri, 20 May 2022 01:16:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyq0jdlYWn/gp/fIo0xS5lYHWZVctDMKraSe7hdBVW8otd+LH9ZV6+PRmPcgORhq/AxFR3W X-Received: by 2002:a05:6402:1612:b0:42a:be18:8c8 with SMTP id f18-20020a056402161200b0042abe1808c8mr9601560edv.223.1653034565518; Fri, 20 May 2022 01:16:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653034565; cv=none; d=google.com; s=arc-20160816; b=pdvqb5IxeQwNdJ8iqK79LzzJTU2WQUtloj29nAvNcD3hOFrJrEERTLMmu6bB70ym1p OkHRBtvzGBDHinoukS8Ne1U+f3qoLUNZs5ijGsN1lxwsejiTfTHELncMqnpqgMrNc4D2 XGkU39SxHNBSMHyJlZgYnc21MyDcfu89l7oqGCh3zy/K1vs8bBgtp4r9jiCvLEFnTYW9 DeSuKbpe4MElQzZAhtMvxg1cQy0PrUpOQNrFkRkjDAzapP58VFh+eGhUzqoAzXpV37uu 8xzjHUqfThWRvDCUlp6fcvCynDNSFpMw2tei7KfmZcNRGLBP6Bz3wX5D37VnW9WaR/OM IiWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=Ni80RitBLZmDace5+J8iGDWdC+N7/xTzTe+btHrPs3I=; b=Xt5S6O7zoVy5a8wNkadWobqCUdLjL6+3qxLEqtgkoCi8ThU8l1TZO85j/WQs8U9wA6 CpGM5MqWBy4xJwBLq7cFsaGxqPO58xJOmw/UhLeF5tRXtxibtsHK+h+qeapfjN1oMAec XVWnqrlG6SOHCmujba5ZarpmHI/K8/BlXc405kXiW2RdtiZTw4ghggG4zkJY8aJL3ipt xFoIoABMD0d+mnWO7vWa9KWtyYj0/LE65AbLTJTmP899kOP+5DKMWviQ7k+jpBQwNSNU nunJatt/E0hJvlYKY5gBsefHHRhtaSCiuAm7oFsunBbPilDclAwpx27CJmXP4VjvVlb7 LR+A== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sd21-20020a1709076e1500b006f414b82bb2si8187911ejc.394.2022.05.20.01.15.39; Fri, 20 May 2022 01:16:05 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242281AbiESQzh (ORCPT + 99 others); Thu, 19 May 2022 12:55:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51996 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242263AbiESQzd (ORCPT ); Thu, 19 May 2022 12:55:33 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6FC5268F92 for ; Thu, 19 May 2022 09:55:32 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2EFF41477; Thu, 19 May 2022 09:55:32 -0700 (PDT) Received: from localhost (ionvoi01-desktop.cambridge.arm.com [10.1.196.65]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C430A3F718; Thu, 19 May 2022 09:55:31 -0700 (PDT) Date: Thu, 19 May 2022 17:55:30 +0100 From: Ionela Voinescu To: Sudeep Holla Cc: Atish Patra , linux-kernel@vger.kernel.org, Atish Patra , Vincent Guittot , Morten Rasmussen , Dietmar Eggemann , Qing Wang , linux-arm-kernel@lists.infradead.org, linux-riscv@lists.infradead.org, Rob Herring Subject: Re: [PATCH v2 3/8] arch_topology: Set cluster identifier in each core/thread from /cpu-map Message-ID: References: <20220518093325.2070336-1-sudeep.holla@arm.com> <20220518093325.2070336-4-sudeep.holla@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220518093325.2070336-4-sudeep.holla@arm.com> X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, 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 Hi, As said before, this creates trouble for CONFIG_SCHED_CLUSTER=y. The output below is obtained from Juno. When cluster_id is populated, a new CLS level is created by the scheduler topology code. In this case the clusters in DT determine that the cluster siblings and llc siblings are the same so the MC scheduler domain will be removed and, for Juno, only CLS and DIE will be kept. root@debian-arm64-buster:/sys/kernel/debug/sched/domains/cpu1# grep . */* domain0/busy_factor:16 domain0/cache_nice_tries:1 domain0/flags:SD_BALANCE_NEWIDLE SD_BALANCE_EXEC SD_BALANCE_FORK SD_WAKE_AFFINE SD_SHARE_PKG_RESOURCES SD_PREFER_SIBLING domain0/imbalance_pct:117 domain0/max_interval:4 domain0/max_newidle_lb_cost:14907 domain0/min_interval:2 domain0/name:CLS domain1/busy_factor:16 domain1/cache_nice_tries:1 domain1/flags:SD_BALANCE_NEWIDLE SD_BALANCE_EXEC SD_BALANCE_FORK SD_WAKE_AFFINE SD_ASYM_CPUCAPACITY SD_ASYM_CPUCAPACITY_FULL SD_PREFER_SIBLING domain1/imbalance_pct:117 domain1/max_interval:12 domain1/max_newidle_lb_cost:11858 domain1/min_interval:6 domain1/name:DIE To be noted that we also get a new flag SD_PREFER_SIBLING for the CLS level that is not appropriate. We usually remove it for the child of a SD_ASYM_CPUCAPACITY domain, but we don't currently redo this after some levels are degenerated. This is a fixable issue. But looking at the bigger picture, a good question is what is the best thing to do when cluster domains and llc domains span the same CPUs? Possibly it would be best to restrict clusters (which are almost an arbitrary concept) to always span a subset of CPUs of the llc domain, if llc siblings can be obtained? If those clusters are not properly set up in DT to respect this condition, cluster_siblings would need to be cleared (or set to the current CPU) so the CLS domain is not created at all. Additionally, should we use cluster information from DT (cluster_id) to create an MC level if we don't have llc information, even if CONFIG_SCHED_CLUSTER=n? I currently don't have a very clear picture of how cluster domains and llc domains would "live" together in a variety of topologies. I'll try other DT topologies to see if there are others that can lead to trouble. Thanks, Ionela. On Wednesday 18 May 2022 at 10:33:20 (+0100), Sudeep Holla wrote: > Let us set the cluster identifier as parsed from the device tree > cluster nodes within /cpu-map. > > We don't support nesting of clusters yet as there are no real hardware > to support clusters of clusters. > > Signed-off-by: Sudeep Holla > --- > drivers/base/arch_topology.c | 13 ++++++++----- > 1 file changed, 8 insertions(+), 5 deletions(-) > > diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c > index 7f5aa655c1f4..bdb6f2a17df0 100644 > --- a/drivers/base/arch_topology.c > +++ b/drivers/base/arch_topology.c > @@ -491,7 +491,7 @@ static int __init get_cpu_for_node(struct device_node *node) > } > > static int __init parse_core(struct device_node *core, int package_id, > - int core_id) > + int cluster_id, int core_id) > { > char name[20]; > bool leaf = true; > @@ -507,6 +507,7 @@ static int __init parse_core(struct device_node *core, int package_id, > cpu = get_cpu_for_node(t); > if (cpu >= 0) { > cpu_topology[cpu].package_id = package_id; > + cpu_topology[cpu].cluster_id = cluster_id; > cpu_topology[cpu].core_id = core_id; > cpu_topology[cpu].thread_id = i; > } else if (cpu != -ENODEV) { > @@ -528,6 +529,7 @@ static int __init parse_core(struct device_node *core, int package_id, > } > > cpu_topology[cpu].package_id = package_id; > + cpu_topology[cpu].cluster_id = cluster_id; > cpu_topology[cpu].core_id = core_id; > } else if (leaf && cpu != -ENODEV) { > pr_err("%pOF: Can't get CPU for leaf core\n", core); > @@ -537,7 +539,8 @@ static int __init parse_core(struct device_node *core, int package_id, > return 0; > } > > -static int __init parse_cluster(struct device_node *cluster, int depth) > +static int __init > +parse_cluster(struct device_node *cluster, int cluster_id, int depth) > { > char name[20]; > bool leaf = true; > @@ -557,7 +560,7 @@ static int __init parse_cluster(struct device_node *cluster, int depth) > c = of_get_child_by_name(cluster, name); > if (c) { > leaf = false; > - ret = parse_cluster(c, depth + 1); > + ret = parse_cluster(c, i, depth + 1); > of_node_put(c); > if (ret != 0) > return ret; > @@ -581,7 +584,7 @@ static int __init parse_cluster(struct device_node *cluster, int depth) > } > > if (leaf) { > - ret = parse_core(c, 0, core_id++); > + ret = parse_core(c, 0, cluster_id, core_id++); > } else { > pr_err("%pOF: Non-leaf cluster with core %s\n", > cluster, name); > @@ -621,7 +624,7 @@ static int __init parse_dt_topology(void) > if (!map) > goto out; > > - ret = parse_cluster(map, 0); > + ret = parse_cluster(map, -1, 0); > if (ret != 0) > goto out_map; > > -- > 2.36.1 > >