Message-ID: <20211217190345.kskfhnelqg3yx4j7@bogus>
Date:   Fri, 17 Dec 2021 19:03:45 +0000
From:   Sudeep Holla <sudeep.holla@....com>
To:     Rob Herring <robh@...nel.org>
Cc:     Robin Murphy <robin.murphy@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        James Morse <james.morse@....com>,
        Sudeep Holla <sudeep.holla@....com>,
        Jeremy Linton <jeremy.linton@....com>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>, devicetree@...r.kernel.org,
        "open list:ACPI FOR ARM64 (ACPI/arm64)" <linux-acpi@...r.kernel.org>
Subject: Re: [PATCH 2/6] cacheinfo: Set cache 'id' based on DT data

On Fri, Dec 17, 2021 at 12:14:22PM -0600, Rob Herring wrote:
> On Fri, Dec 17, 2021 at 10:57 AM Robin Murphy <robin.murphy@....com> wrote:
> >
> > Hi Rob,
> >
> > On 2021-12-16 23:31, Rob Herring wrote:
> > > Use the minimum CPU h/w id of the CPUs associated with the cache for the
> > > cache 'id'. This will provide a stable id value for a given system. As

I am trying to follow the code. IIUC, the level one(I$ and D$) are skipped
in this logic and the private unified cache if any will get the cpu hwid as
the cache id which is all fine. But what happens if there are 2 levels of
unified private cache ? I am assuming we only care about shared caches for
MPAM and ignore private caches which sounds OK but I just wanted to confirm.

> > > we need to check all possible CPUs, we can't use the shared_cpu_map
> > > which is just online CPUs. There's not a cache to CPUs mapping in DT, so
> > > we have to walk all CPU nodes and then walk cache levels.

I would have preferred to add the cache IDs in DT similar to ACPI but I see
you have certain concerns with that which are valid as well.

> >
> > I believe another expected use of the cache ID exposed in sysfs is to
> > program steering tags for cache stashing (typically in VFIO-based
> > userspace drivers like DPDK so we can't realistically mediate it any
> > other way). There were plans afoot last year to ensure that ACPI PPTT
> > could provide the necessary ID values for arm64 systems which will
> > typically be fairly arbitrary (but unique) due to reflecting underlying
> > interconnect routing IDs. Assuming that there will eventually be some
> > interest in cache stashing on DT-based systems too, we probably want to
> > allow for an explicit ID property on DT cache nodes in a similar manner.
> 
> If you have a suggestion for ID values that correspond to the h/w,
> then we can add them. I'd like a bit more than just trusting that ID
> is something real.
>

I agree, probably architecture must do better job at defining these. But
generated IDs IMO might cause issues especial if we have to change the
logic without breaking the backward compatibility.

> While the ACPI folks may be willing to take an arbitrary index, it's
> something we (mostly) avoid for DT.
>

Not sure if we can call that *arbitrary* 😄, in that case we can imagine
the same at several places in the firmware.

> > That said, I think it does make sense to have some kind of
> > auto-generated fallback scheme *as well*, since I'm sure there will be
> > plenty systems which care about MPAM but don't support stashing, and
> > therefore wouldn't have a meaningful set of IDs to populate their DT
> > with. Conversely I think that might also matter for ACPI too - one point
> > I remember from previous discussions is that PPTT may use a compact
> > representation where a single entry represents all equivalent caches at
> > that level, so I'm not sure we can necessarily rely on IDs out of that
> > path being unique either.
> 
> AIUI, cache ids break the compact representation.
>

IIRC, a note was added to avoid compaction if an implementation requires
any cache instance to be referenced uniquely.

-- 
Regards,
Sudeep

Powered by blists - more mailing lists