Messages in this thread | | | Date | Wed, 29 Jun 2022 20:12:50 +0100 | From | Sudeep Holla <> | Subject | Re: [PATCH v5 09/19] arch_topology: Use the last level cache information from the cacheinfo |
| |
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
| |