[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220629191250.mg3dybgl6hnlnqee@bogus>
Date: Wed, 29 Jun 2022 20:12:50 +0100
From: Sudeep Holla <sudeep.holla@....com>
To: Conor.Dooley@...rochip.com
Cc: linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org,
atishp@...shpatra.org, atishp@...osinc.com,
Sudeep Holla <sudeep.holla@....com>,
vincent.guittot@...aro.org, dietmar.eggemann@....com,
wangqing@...o.com, robh+dt@...nel.org, rafael@...nel.org,
ionela.voinescu@....com, pierre.gondois@....com,
linux-arm-kernel@...ts.infradead.org,
linux-riscv@...ts.infradead.org, gshan@...hat.com,
Valentina.FernandezAlanis@...rochip.com
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@...rochip.com wrote:
> On 29/06/2022 19:47, Sudeep Holla wrote:
> > On Wed, Jun 29, 2022 at 06:18:25PM +0000, Conor.Dooley@...rochip.com wrote:
> >> On 29/06/2022 18:49, Conor.Dooley@...rochip.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
Powered by blists - more mailing lists