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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 96A88C433EF for ; Wed, 16 Mar 2022 14:49:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1356872AbiCPOuR (ORCPT ); Wed, 16 Mar 2022 10:50:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35868 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245291AbiCPOuQ (ORCPT ); Wed, 16 Mar 2022 10:50:16 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id B3537344E3; Wed, 16 Mar 2022 07:49:01 -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 708A71476; Wed, 16 Mar 2022 07:49:01 -0700 (PDT) Received: from [192.168.178.6] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A55DF3F766; Wed, 16 Mar 2022 07:48:58 -0700 (PDT) Message-ID: Date: Wed, 16 Mar 2022 15:48:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v3] topology: make core_mask include at least cluster_siblings Content-Language: en-US To: Darren Hart Cc: Vincent Guittot , Will Deacon , LKML , Linux Arm , Sudeep Holla , Greg Kroah-Hartman , "Rafael J. Wysocki" , Catalin Marinas , Peter Zijlstra , Valentin Schneider , "D . Scott Phillips" , Ilkka Koskinen , stable@vger.kernel.org, Barry Song <21cnbao@gmail.com> References: <20220308103012.GA31267@willie-the-truck> <7ac47c67-0b5e-5caa-20bb-a0100a0cb78f@arm.com> <9398d7ad-30e7-890a-3e18-c3011c383585@arm.com> From: Dietmar Eggemann In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org - Barry Song (always get undelivered mail returned to sender) + Barry Song <21cnbao@gmail.com> On 14/03/2022 17:54, Darren Hart wrote: > On Mon, Mar 14, 2022 at 05:35:05PM +0100, Dietmar Eggemann wrote: >> On 09/03/2022 19:26, Darren Hart wrote: >>> On Wed, Mar 09, 2022 at 01:50:07PM +0100, Dietmar Eggemann wrote: >>>> On 08/03/2022 18:49, Darren Hart wrote: >>>>> On Tue, Mar 08, 2022 at 05:03:07PM +0100, Dietmar Eggemann wrote: >>>>>> On 08/03/2022 12:04, Vincent Guittot wrote: >>>>>>> On Tue, 8 Mar 2022 at 11:30, Will Deacon wrote: [...] > Ultimately, this delivers the same result. I do think it imposes more complexity > for everyone to address what as far as I'm aware only affect the one system. > > I don't think the term "Cluster" has a clear and universally understood > definition, so I don't think it's a given that "CLS should be sub-SD of MC". I I agree, the term 'cluster' is overloaded but default_topology[] clearly says (with direction up means smaller SD spans). #ifdef CONFIG_SCHED_CLUSTER { cpu_clustergroup_mask, cpu_cluster_flags, SD_INIT_NAME(CLS) }, #endif #ifdef CONFIG_SCHED_MC { cpu_coregroup_mask, cpu_core_flags, SD_INIT_NAME(MC) }, #endif In ACPI code we have `cluster_node = fetch_pptt_node(... , cpu_node->parent) but then the cache information (via llc_id/llc_sibling) can change things which make this less easy to grasp. > think this has been assumed, and that assumption has mostly held up, but this is > an abstraction, and the abstraction should follow the physical topologies rather > than the other way around in my opinion. If that's the primary motivation for > this approach, I don't think it justifies the additional complexity. > > All told, I prefer the 2 line change contained within cpu_coregroup_mask() which > handles the one known exception with minimal impact. It's easy enough to come > back to this to address more cases with a more complex solution if needed in the > future - but I prefer to introduce the least amount of complexity as possible to > address the known issues, especially if the end result is the same and the cost > is paid by the affected systems. > > Thanks, Yeah, I can see your point. It's the smaller hack. My solution just prevents us to manipulate the coregroup mask only to get the MC layer degenerated by the core topology code. But people might say that's a clever thing to do here. So I'm fine with your original solution as well. [...] 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 95FA4C433EF for ; Wed, 16 Mar 2022 14:50:19 +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:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=5hGDocvNmuImy3OulCxOollMOHZPzFwHHb2l9lc3WQc=; b=DVXEp9cLj7vdvk 6W4unlebrVat9G/1R0v7QD1DPwdERDOzGsXGa7t6FcTLcps+ADNXdkXP3gzdhg4dut8BnfyxgAUnB CQ+oycs2zwJi8FPJyCGijLW6Z/TGGN/GbCnsP5RR6KiHOyExsj337+LJ8eNPpeJRe22dXcpnagbml KTL7JNwbOJWGPA0pUXby7rA9Z6xQAfkO9uecSaz6pVKbAx3qOzceQ7gGmrqdUNvPJB0EWZfHMPu8g OQGdNyOpmIUx5LUBaiXiqMUqfiNCjNsBRAk16BUKv3fBSmtWZn+bGcnM/nhAadn/em2V+pcaTHnnC fNIZVto3FtCoDLUtrVlQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nUUxW-00DKRX-La; Wed, 16 Mar 2022 14:49:06 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nUUxS-00DKQL-Vx for linux-arm-kernel@lists.infradead.org; Wed, 16 Mar 2022 14:49:04 +0000 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 708A71476; Wed, 16 Mar 2022 07:49:01 -0700 (PDT) Received: from [192.168.178.6] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A55DF3F766; Wed, 16 Mar 2022 07:48:58 -0700 (PDT) Message-ID: Date: Wed, 16 Mar 2022 15:48:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v3] topology: make core_mask include at least cluster_siblings Content-Language: en-US To: Darren Hart Cc: Vincent Guittot , Will Deacon , LKML , Linux Arm , Sudeep Holla , Greg Kroah-Hartman , "Rafael J. Wysocki" , Catalin Marinas , Peter Zijlstra , Valentin Schneider , "D . Scott Phillips" , Ilkka Koskinen , stable@vger.kernel.org, Barry Song <21cnbao@gmail.com> References: <20220308103012.GA31267@willie-the-truck> <7ac47c67-0b5e-5caa-20bb-a0100a0cb78f@arm.com> <9398d7ad-30e7-890a-3e18-c3011c383585@arm.com> From: Dietmar Eggemann In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220316_074903_156002_86C17436 X-CRM114-Status: GOOD ( 20.36 ) 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 - Barry Song (always get undelivered mail returned to sender) + Barry Song <21cnbao@gmail.com> On 14/03/2022 17:54, Darren Hart wrote: > On Mon, Mar 14, 2022 at 05:35:05PM +0100, Dietmar Eggemann wrote: >> On 09/03/2022 19:26, Darren Hart wrote: >>> On Wed, Mar 09, 2022 at 01:50:07PM +0100, Dietmar Eggemann wrote: >>>> On 08/03/2022 18:49, Darren Hart wrote: >>>>> On Tue, Mar 08, 2022 at 05:03:07PM +0100, Dietmar Eggemann wrote: >>>>>> On 08/03/2022 12:04, Vincent Guittot wrote: >>>>>>> On Tue, 8 Mar 2022 at 11:30, Will Deacon wrote: [...] > Ultimately, this delivers the same result. I do think it imposes more complexity > for everyone to address what as far as I'm aware only affect the one system. > > I don't think the term "Cluster" has a clear and universally understood > definition, so I don't think it's a given that "CLS should be sub-SD of MC". I I agree, the term 'cluster' is overloaded but default_topology[] clearly says (with direction up means smaller SD spans). #ifdef CONFIG_SCHED_CLUSTER { cpu_clustergroup_mask, cpu_cluster_flags, SD_INIT_NAME(CLS) }, #endif #ifdef CONFIG_SCHED_MC { cpu_coregroup_mask, cpu_core_flags, SD_INIT_NAME(MC) }, #endif In ACPI code we have `cluster_node = fetch_pptt_node(... , cpu_node->parent) but then the cache information (via llc_id/llc_sibling) can change things which make this less easy to grasp. > think this has been assumed, and that assumption has mostly held up, but this is > an abstraction, and the abstraction should follow the physical topologies rather > than the other way around in my opinion. If that's the primary motivation for > this approach, I don't think it justifies the additional complexity. > > All told, I prefer the 2 line change contained within cpu_coregroup_mask() which > handles the one known exception with minimal impact. It's easy enough to come > back to this to address more cases with a more complex solution if needed in the > future - but I prefer to introduce the least amount of complexity as possible to > address the known issues, especially if the end result is the same and the cost > is paid by the affected systems. > > Thanks, Yeah, I can see your point. It's the smaller hack. My solution just prevents us to manipulate the coregroup mask only to get the MC layer degenerated by the core topology code. But people might say that's a clever thing to do here. So I'm fine with your original solution as well. [...] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel