Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp911865pxb; Fri, 22 Apr 2022 14:07:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx3fH+VP9QtAUMQAhD9fQq4ZQXihhZKKJwExa1v3cjasoO7QCErxzO8h4lY4pYU0Po18cSr X-Received: by 2002:a63:a61:0:b0:39c:b654:b753 with SMTP id z33-20020a630a61000000b0039cb654b753mr5340811pgk.117.1650661632249; Fri, 22 Apr 2022 14:07:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650661632; cv=none; d=google.com; s=arc-20160816; b=KQArW9ZIHKDlbTeO0Jz5iNp2+9yPfczBJ7bUxAcDUDTWEvWdBhiT5pYSUNXTT6u9ag O7ouDf5ahACAG2LauJpr+gCitq+DRfrCcTyQTrDBp2a5l7LAYXkdUxa7Swp1eAU9qs1G +F6SQD4EpnjerYIe7FolcaywsQfRu08yexQZJv4Nlj6ITXHkp2Yg8FQo92yvmu9KA3Gg VUlghbSngl9M9MLnxtR1h5RhswQkJtqEmbjh1/qCBYZqrqXBm3R3OxAuu0A9OaLJzFio 6Jn4jfy/GDuGJkZ8KVkpPNX07UuI5Zb7umCE5D1PkmUcfFFKP1Aw7qHEUO/m9985fkB4 N/Sg== 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:dkim-signature; bh=tzkO0k3U4qRnYr3cI4k/yymgz+OA27lWtgiIZB+fuuk=; b=QbRDBjeeIWsCrEnrRzPPdf80aPVbNs+0RM1x+twcNj7R2xfNPOUHWtPvSZT7GyoEuC TmJXQIgVWpTthxbgFUgnmyuv3zikM5HeviU1esuQOCE/UmFUueq2msvpjTjzgwTvGEhF hlSvYhKQ810aK4Zk0p8o1Vr4a7LhFy8hy3TrhJlShorrCAjaDG9OPV8IdIntU7jagPKy AMTxLO2eaHNtVFwQNym/uX3bmKRACdz9WmDUE6ZGv1DHV4V4CLo3EUkmaaKG7VQHxx4y Vj0sMjT0O7xauf38Wh4vQot2llexxRk9AjG5wht/u8Ye4RQLfkPjWFHDDBfYUDGdaSLS 2onw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=q6+ZXnG4; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id n65-20020a632744000000b003aa6195a9f2si9190303pgn.121.2022.04.22.14.07.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 14:07:12 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=q6+ZXnG4; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 3FF65191C5D; Fri, 22 Apr 2022 13:04:42 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1447512AbiDVMd2 (ORCPT + 99 others); Fri, 22 Apr 2022 08:33:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48912 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1447548AbiDVMdZ (ORCPT ); Fri, 22 Apr 2022 08:33:25 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 981A85714A for ; Fri, 22 Apr 2022 05:30:30 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C9F7262016 for ; Fri, 22 Apr 2022 12:30:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 95024C385A4; Fri, 22 Apr 2022 12:30:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1650630629; bh=l/UThzJt7EIh5W2gfH2rbyMyEURpsdabio8nxJX2/N8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=q6+ZXnG4VO5fCl1Ebfighwz76rxZODtuBiM9HyI8n5LXwm2fvI9pn9cD3zGtogan8 JC2XS1g4Drt9bmofls+4vWo1uygB7PcbG70TGUaK9aO/3LVa2XddVq47dUXmO30BYB NvmPSPoSi1AE59bfThsi+ZtMaCe+ZHe8ZMqNf7S0= Date: Fri, 22 Apr 2022 14:30:26 +0200 From: Greg Kroah-Hartman To: Qing Wang Cc: Catalin Marinas , Will Deacon , Sudeep Holla , "Rafael J. Wysocki" , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, vincent.guittot@linaro.org, dietmar.eggemann@arm.com Subject: Re: [PATCH V2 1/2] arch_topology: support for parsing cache topology from DT Message-ID: References: <1650628289-67716-1-git-send-email-wangqing@vivo.com> <1650628289-67716-2-git-send-email-wangqing@vivo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1650628289-67716-2-git-send-email-wangqing@vivo.com> X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE autolearn=unavailable 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 Fri, Apr 22, 2022 at 04:51:25AM -0700, Qing Wang wrote: > From: Wang Qing > > When ACPI is not enabled, we can get cache topolopy from DT like: > * cpu0: cpu@000 { > * next-level-cache = <&L2_1>; > * L2_1: l2-cache { > * compatible = "cache"; > * next-level-cache = <&L3_1>; > * }; > * L3_1: l3-cache { > * compatible = "cache"; > * }; > * }; > * > * cpu1: cpu@001 { > * next-level-cache = <&L2_1>; > * }; > * ... > * }; > cache_topology[] hold the pointer describing by "next-level-cache", > which can describe the cache topology of every level. > > MAX_CACHE_LEVEL is strictly corresponding to the cache level from L2. I have no idea what this changelog means at all. What are you trying to do? What problem are you solving? Why are you doing any of this? > > V2: > make function name more sense As per the documentation this goes below the --- line, right? > > Signed-off-by: Wang Qing > --- > drivers/base/arch_topology.c | 47 ++++++++++++++++++++++++++++++++++- > include/linux/arch_topology.h | 3 +++ > 2 files changed, 49 insertions(+), 1 deletion(-) > > diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c > index 1d6636ebaac5..46e84ce2ec0c 100644 > --- a/drivers/base/arch_topology.c > +++ b/drivers/base/arch_topology.c > @@ -480,8 +480,10 @@ static int __init get_cpu_for_node(struct device_node *node) > return -1; > > cpu = of_cpu_node_to_id(cpu_node); > - if (cpu >= 0) > + if (cpu >= 0) { > topology_parse_cpu_capacity(cpu_node, cpu); > + topology_parse_cpu_caches(cpu_node, cpu); > + } > else > pr_info("CPU node for %pOF exist but the possible cpu range is :%*pbl\n", > cpu_node, cpumask_pr_args(cpu_possible_mask)); > @@ -647,6 +649,49 @@ static int __init parse_dt_topology(void) > } > #endif > > +/* > + * cpu cache topology table > + */ > +#define MAX_CACHE_LEVEL 7 > +static struct device_node *cache_topology[NR_CPUS][MAX_CACHE_LEVEL]; So for a normal big system of 4k cpus * 7 levels, that's a lot of memory? are you sure? How big of a box did you test this on? > + > +void topology_parse_cpu_caches(struct device_node *cpu_node, int cpu) > +{ > + struct device_node *node_cache = cpu_node; > + int level = 0; > + > + while (level < MAX_CACHE_LEVEL) { > + node_cache = of_parse_phandle(node_cache, "next-level-cache", 0); > + if (!node_cache) > + break; > + > + cache_topology[cpu][level++] = node_cache; > + } No locking anywhere? What could go wrong :( > +} > + > +/* > + * find the largest subset of the shared cache in the range of cpu_mask > + */ > +void find_subset_of_share_cache(const struct cpumask *cpu_mask, int cpu, > + struct cpumask *sc_mask) Again, horrid global function name. And no kernel documentation for how this works? > +{ > + int cache_level, cpu_id; > + > + for (cache_level = MAX_CACHE_LEVEL - 1; cache_level >= 0; cache_level--) { > + if (!cache_topology[cpu][cache_level]) > + continue; No locking??? > + > + cpumask_clear(sc_mask); > + for (cpu_id = 0; cpu_id < NR_CPUS; cpu_id++) { > + if (cache_topology[cpu][cache_level] == cache_topology[cpu_id][cache_level]) > + cpumask_set_cpu(cpu_id, sc_mask); > + } > + > + if (cpumask_subset(sc_mask, cpu_mask)) > + break; > + } > +} > + > /* > * cpu topology table > */ > diff --git a/include/linux/arch_topology.h b/include/linux/arch_topology.h > index 58cbe18d825c..c6ed727e453c 100644 > --- a/include/linux/arch_topology.h > +++ b/include/linux/arch_topology.h > @@ -93,6 +93,9 @@ void update_siblings_masks(unsigned int cpu); > void remove_cpu_topology(unsigned int cpuid); > void reset_cpu_topology(void); > int parse_acpi_topology(void); > +void topology_parse_cpu_caches(struct device_node *cpu_node, int cpu); > +void find_subset_of_share_cache(const struct cpumask *cpu_mask, int cpu, > + struct cpumask *sc_mask); I still have no idea what this last function is supposed to do. And very odd indentation, did you run checkpatch on this? totally confused, greg k-h