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 5774BC433EF for ; Fri, 20 May 2022 15:07:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350595AbiETPHI (ORCPT ); Fri, 20 May 2022 11:07:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52562 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345536AbiETPHE (ORCPT ); Fri, 20 May 2022 11:07:04 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E56486CF51 for ; Fri, 20 May 2022 08:07: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 A884F1477; Fri, 20 May 2022 08:07:01 -0700 (PDT) Received: from bogus (unknown [10.57.66.157]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A4E6E3F73D; Fri, 20 May 2022 08:06:59 -0700 (PDT) Date: Fri, 20 May 2022 16:06:52 +0100 From: Sudeep Holla To: Rob Herring Cc: Atish Patra , "linux-kernel@vger.kernel.org" , Atish Patra , Sudeep Holla , Vincent Guittot , Morten Rasmussen , Dietmar Eggemann , Qing Wang , linux-arm-kernel , linux-riscv Subject: Re: [PATCH v2 8/8] arch_topology: Add support to build llc_sibling on DT platforms Message-ID: <20220520150652.n6cfl7qpzbjrjh2f@bogus> References: <20220518093325.2070336-1-sudeep.holla@arm.com> <20220518093325.2070336-9-sudeep.holla@arm.com> <20220520125959.wlxz53cfqldljxjy@bogus> <20220520143620.GA3788938-robh@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220520143620.GA3788938-robh@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 20, 2022 at 09:36:20AM -0500, Rob Herring wrote: > On Fri, May 20, 2022 at 01:59:59PM +0100, Sudeep Holla wrote: > > On Thu, May 19, 2022 at 01:10:51PM -0500, Rob Herring wrote: > > > On Wed, May 18, 2022 at 4:34 AM Sudeep Holla wrote: > > > > > > > > ACPI PPTT provides cache identifiers and especially the last level cache > > > > identifier is used in obtaining last level cache siblings amongst CPUs. > > > > > > > > While we have the cpu map representing all the CPUs sharing last level > > > > cache in the cacheinfo driver, it is populated quite late in the boot > > > > while the information is needed to build scheduler domains quite early. > > > > > > Late is because it's a device_initcall() rather than late in the cpu > > > hotplug state machine, right? > > > > Right. The expectation is to run in on each online CPU in CPU hotplug state > > machine for some architectures. We may not need that on arm64 especially > > since we get all info from DT or ACPI, but e.g. x86 uses cpuid which needs > > to be executed on that CPU. > > That's a separate issue. I'm not suggesting changing that part (that > would just be an optimization). > > > > The late aspect is for sysfs presumably,but I think we could decouple that. > > > > OK, not sure when this sched_domain info is actually needed. It think it > > could be decoupled if we can wait until all the cpus are online. > > No need to wait for all cpus to be online. I think you keep doing > it as part of cpu hotplug. The device_initcall() is used because you > cannot have struct device or sysfs calls before the driver core is > initialized. If we run the cacheinfo code earlier (I think the arch code > will have to call it) just like the topology code and skip the sysfs > parts, then you can use it. > Yes I was thinking something on similar lines, though I didn't think of pushing code to arch. Let me check, must be possible. > > > Do all the firmware cache parsing early and then populate the sysfs parts > > > later. > > > > Yes that may work on DT/ACPI based systems, as I said x86 relies on cpuid. > > I'd assume using cpuid works at any time? > I think so, I can't recall the details since I looked at that about 5 years ago. I have to check again anyways to explore early initialisation. -- Regards, Sudeep 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 6BCC0C433EF for ; Fri, 20 May 2022 15:07:28 +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:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZFgtgQCshuDppRzRb7lSf41U9yATrGkDJc6VTkAuyF4=; b=lBEKZapN/GGBHs u5Z49WAWxacjiJm9uvzPvFEWV3xBXbY2FSn9ZeuBLcZDyqrEHFB8k1kfOyotLSn/g6WUEcIRtgvVK jlHbjsaE2WTfmggQFtV6CPNF95nOysjc8mT5KOf+3KEmh0E/qsztAz7kP7TAQrCFcgKm5sanEABiI laqsUXx8D8mrisAL7M/235e48t41ovP/II4vLhjlat1krlub3RAj6WrJM1HFgPpEITlYJj4t7RI5p P+UKHTHfu13OCN8zRpazg6ROeupQ4CLscsIH57nffAiBSvW+pC7EJeUwIpWxaghkkDY8KmbmaBVI4 lCjgyWW/Uoo5NIoEQ7JQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ns4Dj-00D4XY-G6; Fri, 20 May 2022 15:07:15 +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 1ns4DX-00D4Tt-AB; Fri, 20 May 2022 15:07: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 A884F1477; Fri, 20 May 2022 08:07:01 -0700 (PDT) Received: from bogus (unknown [10.57.66.157]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A4E6E3F73D; Fri, 20 May 2022 08:06:59 -0700 (PDT) Date: Fri, 20 May 2022 16:06:52 +0100 From: Sudeep Holla To: Rob Herring Cc: Atish Patra , "linux-kernel@vger.kernel.org" , Atish Patra , Sudeep Holla , Vincent Guittot , Morten Rasmussen , Dietmar Eggemann , Qing Wang , linux-arm-kernel , linux-riscv Subject: Re: [PATCH v2 8/8] arch_topology: Add support to build llc_sibling on DT platforms Message-ID: <20220520150652.n6cfl7qpzbjrjh2f@bogus> References: <20220518093325.2070336-1-sudeep.holla@arm.com> <20220518093325.2070336-9-sudeep.holla@arm.com> <20220520125959.wlxz53cfqldljxjy@bogus> <20220520143620.GA3788938-robh@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220520143620.GA3788938-robh@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220520_080703_436691_CBC265DF X-CRM114-Status: GOOD ( 31.98 ) X-BeenThere: linux-riscv@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-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Fri, May 20, 2022 at 09:36:20AM -0500, Rob Herring wrote: > On Fri, May 20, 2022 at 01:59:59PM +0100, Sudeep Holla wrote: > > On Thu, May 19, 2022 at 01:10:51PM -0500, Rob Herring wrote: > > > On Wed, May 18, 2022 at 4:34 AM Sudeep Holla wrote: > > > > > > > > ACPI PPTT provides cache identifiers and especially the last level cache > > > > identifier is used in obtaining last level cache siblings amongst CPUs. > > > > > > > > While we have the cpu map representing all the CPUs sharing last level > > > > cache in the cacheinfo driver, it is populated quite late in the boot > > > > while the information is needed to build scheduler domains quite early. > > > > > > Late is because it's a device_initcall() rather than late in the cpu > > > hotplug state machine, right? > > > > Right. The expectation is to run in on each online CPU in CPU hotplug state > > machine for some architectures. We may not need that on arm64 especially > > since we get all info from DT or ACPI, but e.g. x86 uses cpuid which needs > > to be executed on that CPU. > > That's a separate issue. I'm not suggesting changing that part (that > would just be an optimization). > > > > The late aspect is for sysfs presumably,but I think we could decouple that. > > > > OK, not sure when this sched_domain info is actually needed. It think it > > could be decoupled if we can wait until all the cpus are online. > > No need to wait for all cpus to be online. I think you keep doing > it as part of cpu hotplug. The device_initcall() is used because you > cannot have struct device or sysfs calls before the driver core is > initialized. If we run the cacheinfo code earlier (I think the arch code > will have to call it) just like the topology code and skip the sysfs > parts, then you can use it. > Yes I was thinking something on similar lines, though I didn't think of pushing code to arch. Let me check, must be possible. > > > Do all the firmware cache parsing early and then populate the sysfs parts > > > later. > > > > Yes that may work on DT/ACPI based systems, as I said x86 relies on cpuid. > > I'd assume using cpuid works at any time? > I think so, I can't recall the details since I looked at that about 5 years ago. I have to check again anyways to explore early initialisation. -- Regards, Sudeep _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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 61534C433F5 for ; Fri, 20 May 2022 15:08:10 +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:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=mvPapWVLi93iv1ei+TWbh7GfKbdE67lPD39Q7SLFaV0=; b=SlUErAOQNSjETs W/EayM2+vi8P6QEh93mWpCRg1U/oBGjhq9PXbkYmhJdGLVbD4kKjkLv6Up4Q1ALw8A9UG71FznlKy H3HMqyRHjc1nGusYBz9hRtGLxb88XrYM1PBAas/px5tfWABta+q70o70g+KPcCAN8UFNw303gzMzH 2wU/NxRIqRw4r62x2M5FlIbBhQrq1NgfJ9f3RL2KC3X7ny/kZy3w52mmmUD2vLRaw0cxve2wzQGho b8SndBQGXKl26YX+vedgNHaKwKkN51bBiv/krgRynXvZMEF9SAeavP1EWQ29FFQ7PbUHPGW6wUUsX zsrB08ep4ld5BWZv4wuw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ns4DZ-00D4Um-U2; Fri, 20 May 2022 15:07: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 1ns4DX-00D4Tt-AB; Fri, 20 May 2022 15:07: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 A884F1477; Fri, 20 May 2022 08:07:01 -0700 (PDT) Received: from bogus (unknown [10.57.66.157]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A4E6E3F73D; Fri, 20 May 2022 08:06:59 -0700 (PDT) Date: Fri, 20 May 2022 16:06:52 +0100 From: Sudeep Holla To: Rob Herring Cc: Atish Patra , "linux-kernel@vger.kernel.org" , Atish Patra , Sudeep Holla , Vincent Guittot , Morten Rasmussen , Dietmar Eggemann , Qing Wang , linux-arm-kernel , linux-riscv Subject: Re: [PATCH v2 8/8] arch_topology: Add support to build llc_sibling on DT platforms Message-ID: <20220520150652.n6cfl7qpzbjrjh2f@bogus> References: <20220518093325.2070336-1-sudeep.holla@arm.com> <20220518093325.2070336-9-sudeep.holla@arm.com> <20220520125959.wlxz53cfqldljxjy@bogus> <20220520143620.GA3788938-robh@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220520143620.GA3788938-robh@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220520_080703_436691_CBC265DF X-CRM114-Status: GOOD ( 31.98 ) 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 On Fri, May 20, 2022 at 09:36:20AM -0500, Rob Herring wrote: > On Fri, May 20, 2022 at 01:59:59PM +0100, Sudeep Holla wrote: > > On Thu, May 19, 2022 at 01:10:51PM -0500, Rob Herring wrote: > > > On Wed, May 18, 2022 at 4:34 AM Sudeep Holla wrote: > > > > > > > > ACPI PPTT provides cache identifiers and especially the last level cache > > > > identifier is used in obtaining last level cache siblings amongst CPUs. > > > > > > > > While we have the cpu map representing all the CPUs sharing last level > > > > cache in the cacheinfo driver, it is populated quite late in the boot > > > > while the information is needed to build scheduler domains quite early. > > > > > > Late is because it's a device_initcall() rather than late in the cpu > > > hotplug state machine, right? > > > > Right. The expectation is to run in on each online CPU in CPU hotplug state > > machine for some architectures. We may not need that on arm64 especially > > since we get all info from DT or ACPI, but e.g. x86 uses cpuid which needs > > to be executed on that CPU. > > That's a separate issue. I'm not suggesting changing that part (that > would just be an optimization). > > > > The late aspect is for sysfs presumably,but I think we could decouple that. > > > > OK, not sure when this sched_domain info is actually needed. It think it > > could be decoupled if we can wait until all the cpus are online. > > No need to wait for all cpus to be online. I think you keep doing > it as part of cpu hotplug. The device_initcall() is used because you > cannot have struct device or sysfs calls before the driver core is > initialized. If we run the cacheinfo code earlier (I think the arch code > will have to call it) just like the topology code and skip the sysfs > parts, then you can use it. > Yes I was thinking something on similar lines, though I didn't think of pushing code to arch. Let me check, must be possible. > > > Do all the firmware cache parsing early and then populate the sysfs parts > > > later. > > > > Yes that may work on DT/ACPI based systems, as I said x86 relies on cpuid. > > I'd assume using cpuid works at any time? > I think so, I can't recall the details since I looked at that about 5 years ago. I have to check again anyways to explore early initialisation. -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel