Re: [RFC PATCH mpam mpam/snapshot/v6.12-rc1 v3 2/5] arm_mpam: Read monitor value with new closid/rmid pair

[Dave Martin <Dave.Martin@arm.com>]

Hi,

On Sat, Dec 07, 2024 at 05:21:33PM +0800, Zeng Heng wrote:
> The MPAM driver statically assigns all reqPARTIDs to respective intPARTIDs.
> For the new rmid allocation strategy, it will check if there is an
> available rmid of any reqPARTID which belongs to the input closid, not just
> the rmids belonging to the closid.
> 
> For a mixture of MSCs system, for MSCs that do not support narrow-partid,
> we use the PARTIDs exceeding the number of closids as reqPARTIDs for
> expanding the monitoring groups.
> 
> In order to keep the existing resctrl API interface, the rmid contains both
> req_idx and PMG information instead of PMG only under the MPAM driver. The
> req_idx represents the req_idx-th sub-monitoring group under the control
> group. The new rmid would be like:
> 
>     rmid = (req_idx << shift | pmg).
> 
> The mapping relationships between each group's closid/rmid and the
> respective MSCs' intPARTID/reqPARTID/PARTID are illustrated:
> 
> n - Indicates the total number of intPARTIDs
> m - Indicates the number of reqPARTIDs per intPARTID
> 
> P - Partition group (control group)
> M - Monitoring group
> 
> Group closid rmid.req_idx (req)PARTID      MSCs with narrow-partid  MSCs without narrow-partid
> P1    0      -            0                   intPARTID_1              PARTID_1
> M1_1  0      0            0                       ├── reqPARTID_1_1       ├── PARTID_1_1
> M1_2  0      1            0+n                     ├── reqPARTID_1_2       ├── PARTID_1_2
> M1_3  0      2            0+n*2                   ├── reqPARTID_1_3       ├── PARTID_1_3
>  ...                                              ├── ...                 ├── ...
> M1_m  0      (m-1)        0+n*(m-1)               └── reqPARTID_1_m       └── PARTID_1_m
> 
> P2    1      -            1                   intPARTID_2              PARTID_2
> M2_1  1      0            1                       ├── reqPARTID_2_1       ├── PARTID_2_1
> M2_2  1      1            1+n                     ├── reqPARTID_2_2       ├── PARTID_2_2
> M2_3  1      2            1+n*2                   ├── reqPARTID_2_3       ├── PARTID_2_3
>  ...                                              ├── ...                 ├── ...
> M2_m  1      (m-1)        1+n*(m-1)               └── reqPARTID_2_m       └── PARTID_2_m
> 
> Pn    (n-1)  -            (n-1)               intPARTID_n              PARTID_n
> Mn_1  (n-1)  0            (n-1)                   ├── reqPARTID_n_1       ├── PARTID_n_1
> Mn_2  (n-1)  1            (n-1)+n                 ├── reqPARTID_n_2       ├── PARTID_n_2
> Mn_3  (n-1)  2            (n-1)+n*2               ├── reqPARTID_n_3       ├── PARTID_n_3
>  ...                                              ├── ...                 ├── ...
> Mn_m  (n-1)  (m-1)        (n-1)+n*(m-1) = n*m-1   └── reqPARTID_n_m       └── PARTID_n_m
> 
> Based on the example provided, the conversion relationship between
> closid/rmid and (req)PARTID/PMG is:
> 
>     (req)PARTID = (rmid.req_idx * n) + closid,
>     PMG = rmid.pmg.

It seemed more natural to me for the PARTIDs assigned to a particular
CLOSID to be consecutively numbered (see [1]), though it works either
way.

Otherwise, the approach makes sense.

[...]

Cheers
---Dave


[1] [RFC PATCH 4/6] arm_mpam: Introduce flexible CLOSID/RMID translation
https://lore.kernel.org/lkml/20241212154000.330467-5-Dave.Martin@arm.com/