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 986F8C6FD1D for ; Thu, 30 Mar 2023 06:58:38 +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-Type: Content-Transfer-Encoding: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=pg9c4C1k8aDY6jO1cFnA2nJ1jWQ3cGCePtuY8PrX+kA=; b=vJpLiRf80McAEk cDFRgjbsFWKdwVxCFnnfUYxWYbrRgAOgMf5ed+yZNILObhvCxtYpTChv2equ/6VSeED2EPHK7tEdQ 1GjSooIkWJF5E2R4EVpeOSege0BYuTUrPZdJm5Z/IUjBbufv/ptzXFihuOhnx9VHlAy0eO97IXPy7 eHrFNW7XLol0XiBLAfG9M3A+T9+/sizeraiB23M0SOz7JkUq3E6e1eC1slNpICwQpW0BYIRdC9Ju2 b0JefhZLFARtaY+gj35CnhTuk2g5cPFmtJUbwTScquWxtkeG9YJi9J9cFMqGfJWIQdCS64xJle7zS zIdqzcWQ+fWymuUd+d9g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1phmEI-002plQ-2S; Thu, 30 Mar 2023 06:57:50 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1phmEF-002pjJ-0R for linux-arm-kernel@lists.infradead.org; Thu, 30 Mar 2023 06:57:49 +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 5E5012F4; Wed, 29 Mar 2023 23:58:26 -0700 (PDT) Received: from [192.168.1.12] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C2D263F73F; Wed, 29 Mar 2023 23:57:40 -0700 (PDT) Message-ID: Date: Thu, 30 Mar 2023 08:57:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [RFC PATCH] arch_topology: Pre-allocate cacheinfo from primary CPU To: Radu Rendec , Sudeep Holla Cc: linux-arm-kernel@lists.infradead.org, Adrien Thierry , Eric Chanudet References: <20230323224242.31142-1-rrendec@redhat.com> <428070eb-d1d0-cd04-53c7-91e13ab64867@arm.com> <20230329150308.aaajdsh74olpjach@bogus> Content-Language: en-US From: Pierre Gondois In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230329_235747_265328_2B13A600 X-CRM114-Status: GOOD ( 26.96 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 3/29/23 23:35, Radu Rendec wrote: > On Wed, 2023-03-29 at 17:39 +0200, Pierre Gondois wrote: >> On 3/29/23 17:03, Sudeep Holla wrote: >>> On Wed, Mar 29, 2023 at 04:42:07PM +0200, Pierre Gondois wrote: >>>> >>>> This would mean that for all architectures, the cacheinfo would come from >>>> ACPI/DT first..... >>> >>> x86 doesn't fall into the above category. So we need to ensure it continues >>> to work with no errors. >> >> Ok, then maybe having a second arch specific function like >> init_cache_level() would work. >> >> This function would be called in fetch_cache_info() after >> init_of_cache_level()/acpi_get_cache_info() fail. It would fetch >> cache info anywhere but in DT/ACPI. >> Archs that don't want it would not implement it, and it would >> allow the others to get the num_leaves/levels during early boot. > > Hello Pierre, > > If I understand correctly, in the case of arm64 this new function would > use CLIDR_EL1 to detect the number of leaves/levels, right? But since > init_cpu_topology() calls fetch_cache_info() for each CPU, doesn't this > mean we would end up doing CLIDR_EL1 based detection for the secondary > CPUs by running the (arch specific) detection code on the primary CPU? Yes indeed, this would rely on the assumption made in the RFC that the platform is symmetrical (i.e. all CPUs have the same number/level of caches). > > My intimate knowledge of arm64 is very limited, but I *assumed* one of > the reasons why detect_cache_attributes() (and init_cache_level()) run > on the secondary CPU today is because not all CPUs are necessarily > identical. Another possible reason I can think of is because maybe on > some architectures auto-detection isn't possible altogether before the > secondary CPU is brought up. Yes I think you are right. > > In particular, for arm64 is it possible that CLIDR_EL1 may not look the > same depending on the CPU that reads it? What about SoC's with > asymmetrical CPU cores? (no concrete example here, just assuming this > is a real/possible thing) This would indeed be an issue if all the CPUs don't have the same number/level of caches. In case there is no DT/ACPI, it should be possible to: - from the primary CPU using CLIDR_EL1, allocate the cacheinfo (making the assumption the platform is symmetrical) - from the secondary CPUs, if we know a pre-allocation has been made, run init_cache_level() and check the pre-allocation was correct. If not, re-allocate the cacheinfo (and trigger a warning). I think this is more or less what was done in the RFC, the only difference being there is no call from smp_prepare_cpus(), or did I miss something ? Regards, Pierre _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel