Re: [PATCH v5 09/19] arch_topology: Use the last level cache information from the cacheinfo

From: Sudeep Holla <sudeep.holla@arm.com>
To: Conor.Dooley@microchip.com
Cc: linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org,
	atishp@atishpatra.org, atishp@rivosinc.com,
	Sudeep Holla <sudeep.holla@arm.com>,
	vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
	wangqing@vivo.com, robh+dt@kernel.org, rafael@kernel.org,
	ionela.voinescu@arm.com, pierre.gondois@arm.com,
	linux-arm-kernel@lists.infradead.org,
	linux-riscv@lists.infradead.org, gshan@redhat.com,
	Valentina.FernandezAlanis@microchip.com
Subject: Re: [PATCH v5 09/19] arch_topology: Use the last level cache information from the cacheinfo
Date: Wed, 29 Jun 2022 20:12:50 +0100	[thread overview]
Message-ID: <20220629191250.mg3dybgl6hnlnqee@bogus> (raw)
In-Reply-To: <88ef07ea-fbde-b997-6c0c-99f5fb7be201@microchip.com>

On Wed, Jun 29, 2022 at 06:56:29PM +0000, Conor.Dooley@microchip.com wrote:
> On 29/06/2022 19:47, Sudeep Holla wrote:
> > On Wed, Jun 29, 2022 at 06:18:25PM +0000, Conor.Dooley@microchip.com wrote:
> >> On 29/06/2022 18:49, Conor.Dooley@microchip.com wrote:
> >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >>>
> >>> On 27/06/2022 17:50, Sudeep Holla wrote:
> >>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >>>>
> >>>> The cacheinfo is now initialised early along with the CPU topology
> >>>> initialisation. Instead of relying on the LLC ID information parsed
> >>>> separately only with ACPI PPTT elsewhere, migrate to use the similar
> >>>> information from the cacheinfo.
> >>>>
> >>>> This is generic for both DT and ACPI systems. The ACPI LLC ID information
> >>>> parsed separately can now be removed from arch specific code.
> >>>
> >>> Hey Sudeep,
> >>> I bisected broken boot on PolarFire SoC to this patch in next-20220629 :/
> >>> I suspect the issue is a missing "next-level-cache" in the the dt:
> >>> arch/riscv/boot/dts/microchip/mpfs.dtsi
> > 
> > Good that I included this in -next, I had not received any feedback from
> > RISC-V even after 5 iterations.
> 
> I'll be honest, I saw the titles and CC list and made some incorrect
> assumptions as to whether looking at it was worthwhile! I am not at
> this all too long and what is/isn't important to look at often is not
> obvious to me.

No worries, that's why I thought better to include in -next to get some
attention and I did get it this time, hurray! 😄

> But hey, our CI boots -next every day for a reason ;)
>

Good to know and that is really great. Anyways let me know if the diff I sent
helps. I strongly suspect that is the reason, but I may be wrong.

> > I also see this DTS is very odd. It also
> > states CPU0 doesn't have L1-D$ while the other 4 CPUs have L1-D$. Is that
> > a mistake or is it the reality ?
> 
> AFAIK, reality. It's the same for the SiFive fu540 (with which this shares
> a core complex. See page 12:
> https://static.dev.sifive.com/FU540-C000-v1.0.pdf
> 
> > Another breakage in userspace cacheinfo
> > sysfs entry of cpu0 has both I$ and D$.
> 
> Could you clarify what this means please?

Ignore me if the cpu0 really doesn't have L1-D$. However the userspace
sysfs cacheinfo is incomplete without linking L2, so it can be considered
as wrong info presented to the user.

Check /sys/devices/system/cpu/cpu<n>/cache/index<i>/*.
L2 won't be present there as the link with next-level-cache is missing.
So userspace can interpret this as absence of L2.

-- 
Regards,
Sudeep

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