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

[Zeng Heng <zengheng4@huawei.com>]

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