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

[Zeng Heng]

On 2024/12/13 0:18, Dave Martin wrote:
> 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.

Yes, I agree with your point and it would be included in the next 
version soon.


Best Regards,
Zeng Heng