Re: [RFC PATCH] arch_topology: Pre-allocate cacheinfo from primary CPU

From: Radu Rendec <rrendec@redhat.com>
To: Pierre Gondois <pierre.gondois@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	Adrien Thierry <athierry@redhat.com>,
	 Eric Chanudet <echanude@redhat.com>
Subject: Re: [RFC PATCH] arch_topology: Pre-allocate cacheinfo from primary CPU
Date: Wed, 29 Mar 2023 17:35:15 -0400	[thread overview]
Message-ID: <b3d5ee2d28c43e79000036e594b4b17ba44cada2.camel@redhat.com> (raw)
In-Reply-To: <eaaf5620-77d3-0e8a-aab5-e6013f71e194@arm.com>

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?

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.

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)

Best regards,
Radu

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel