Re: [EXT] Re: [PATCH v1 13/14] arm_mpam: Handle resource instances mapped to different controls

[Peter Newman]

[CC Tony Luck]

Hi Amit,

On Fri, Jan 19, 2024 at 5:01 AM Amit Singh Tomar <amitsinght@xxxxxxxxxxx> wrote:
>
> Hi Peter,
>
> Thanks for having a look.
>
> -----Original Message-----
> From: Peter Newman <peternewman@xxxxxxxxxx>
> Sent: Wednesday, January 17, 2024 11:33 PM
> To: Amit Singh Tomar <amitsinght@xxxxxxxxxxx>
> Cc: linux-kernel@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; fenghua.yu@xxxxxxxxx; reinette.chatre@xxxxxxxxx; james.morse@xxxxxxx; George Cherian <gcherian@xxxxxxxxxxx>; robh@xxxxxxxxxx; dfustini@xxxxxxxxxxxx; jonathan.cameron@xxxxxxxxxx
> Subject: [EXT] Re: [PATCH v1 13/14] arm_mpam: Handle resource instances mapped to different controls
>
> External Email
>
> ----------------------------------------------------------------------
> Hi Amit,
>
> On Wed, Jan 17, 2024 at 6:15 AM Amit Singh Tomar <amitsinght@xxxxxxxxxxx> wrote:
>
> >
> > +/* Club different resource properties under a class that resctrl
> > +uses,
> > + * for instance, L3 cache that supports both CPOR, and DSPRI need to
> > +have
> > + * knowledge of both cpbm_wd and dspri_wd. This is needed when two
> > +controls
> > + * are enumerated under differnt RIS Index.
> > + */
> > +static void mpam_enable_club_class_features(struct mpam_class *class,
> > +                                           struct mpam_msc_ris *ris)
>
> It looks like "club" is used as a synonym to "class" here to evade the bigger issue that mpam_classes are not defined correctly as DSPRI resources should not be in the same mpam_class as the L3 CPOR and CSU features.
>
> This hardware makes it clear that the definition of mpam_class as all resources in a (level x {memory,cache}) needs to be revised.
>
> On Marvell platform, DSPRI control register (MPAMCFG_PRI_NS), and Identification Register (MPAMF_PRI_IDR_NS)  are implemented within the LLC MPAM block (the address range contains control and identification registers for CPOR, and DSPRI), and therefore we treat DSPRI as one of the L3 resource. However, suppose we approach it as totally different standalone resource type (PRI) other than Cache storage resource type (CPOR, and CCAP), and define a new MPAM class type for it, there is no standard way to discover this new resource type (PRI) from ACPI tables.
>
> I'm concerned about accessing DSPRI related registers, if we are going to tide it to new MPAM class (as we discover whole L3 MPAM block using firmware tables, and tide it's resources to L3 MPAM class).

This is becoming more of a discussion of MPAM (and resctrl) in
general, so I hope James can participate. Also I should point out that
when discussing MPAM, "resource" refers to a non-RIS MSC or a single
RIS-index on a RIS-enabled MSC, while the "mpam_class" structure in
the code is the counterpart to what RDT (and resctrl) call a resource.

>From my reading of the code, the consequence of (RIS) resources being
in the same mpam_class is that they can be programmed uniformly
through a single schema line in the schemata file, so
__resource_props_mismatch() goes to work on eliminating any resources
(and extra control granularity) which are not programmed exactly the
same way. This function seems more geared toward big.LITTLE systems
where the cache controls on one cluster are dissimilar from those on
the peer cluster and would need to be normalized (James, can you
confirm?). But in this situation, it seems like a better idea to
present a separate schema for one cluster's controls from the others.
For example, "L2P" and "L2E", with non-overlapping domains.

In the case of an MSC implementing RIS, the controls are independent
by definition, so I can't see why the work done in
__resource_props_mismatch() would be applicable.

-Peter