[PATCH v8 next 04/10 Resend v2] arm_mpam: Refactor rmid to reqPARTID/PMG mapping

[Zeng Heng]

Hi James,

>> @@ -478,6 +518,7 @@ static int __read_mon(struct mpam_resctrl_mon *mon, struct mpam_component *mon_c
>>   		      enum resctrl_conf_type cdp_type, u32 closid, u32 rmid, u64 *val)
>>   {
>>   	struct mon_cfg cfg;
>> +	u32 reqpartid = rmid2reqpartid(rmid);
>>   
>>   	if (!mpam_is_enabled())
>>   		return -EINVAL;
>> @@ -493,8 +534,8 @@ static int __read_mon(struct mpam_resctrl_mon *mon, struct mpam_component *mon_c
>>   	cfg = (struct mon_cfg) {
>>   		.mon = mon_idx,
>>   		.match_pmg = true,
>> -		.partid = closid,
>> -		.pmg = rmid,
>> +		.partid = (cdp_type == CDP_CODE) ? reqpartid + 1 : reqpartid,
>> +		.pmg = rmid2pmg(rmid),
> 
> Not using the CLOSID here breaks multiple control groups.
> 

After carefully reviewing your comments and Martin's patch series,
I tried to understand why there's insistence that CLOSID information
is necessary to support multiple control groups, but that's actually
not the case.

Before proceeding, allow me to introduce CPARTID (control partition ID,
no longer borrowing the intPARTID concept). All partids_per_closid
PARTIDs associated with it share the same control scheme under this
CPARTID.

Each PARTID within the partids_per_closid associated with a CPARTID is
called MPARTID (monitor partition ID, no longer borrowing the reqPARTID
concept). It refers to the PARTID used to represent different monitoring
groups under the same control scheme.

I've summarized the ID conversion diagrams from you and Martin as
follows:

  +-------------------------+-----+------------------+
  |          CLOSID         |{CDP}|       RMID       |
  +-------------------------+-----+------------+-----+
  |                   MPARTID                  | PMG |
  +-------------------------------+------------+     |
  |    MPARTID_hi (base_partid)   : MPARTID_lo |     |
  +-------------------------------+------------+-----+

Where (closid|cdp) = base_partid,
               rmid = mpartid_lo * pmg_num + pmg,
        and mpartid = base_partid * partids_per_closid + mpartid_lo,
with mpartid_lo in the range [0, partids_per_closid).

In this scheme, CLOSID and RMID are coupled together to form MPARTID,
which represents the monitor group PARTID.



In current patchset design, decoupling CLOSID and RMID, letting them
represent CPARTID and (MPARTID,PMG) pair respectively, rather than
having RMID depend on CLOSID to derive MPARTID. This decoupling is
essential for future dynamic allocation, because the relationship
between MPARTID and CPARTID must rely on table lookup rather than linear
mapping. If don't decouple in the static allocation design, we would
need another refactor when considering dynamic allocation extensibility.

  +-------------------------------------------+-----+
  |                    CLOSID                 |{CDP}|
  +-------------------------------------------+-----+
  |              CPARTID (base_partid)              |
  +-------------------------------------------------+

  +-----------------------------------+-----+-------+
  |                   RMID_hi         |{CDP}|RMID_lo|
  +-----------------------------------+-----+-------+
  |                   MPARTID               |  PMG  |
  +--------------+--------------------------+       |
  |  MPARTID_hi  : MPARTID_lo (base_partid) |       |
  +--------------+--------------------------+-------+

Where (closid|cdp) = base_partid,
            rmid_lo = pmg,
  and (rmid_hi|cdp) = mpartid = mpartid_hi * (partid_num / 
partids_per_closid) + base_partid,
with mpartid_hi in the range [0, partids_per_closid).

The reason of using base_partid as MPARTID_lo is to keep base_partid
contiguous and CLOSIDs are allocated contiguously. This does mean
MPARTIDs under the same CPARTID won't be contiguous, but that's
inherently difficult to guarantee with dynamic allocation anyway.


The control path uses CLOSID alone (CPARTID), and the monitor path uses
RMID alone (the (MPARTID, PMG) pair). This definition also aligns
closely with the native resctrl concepts: CLOSID (Class of Service ID,
corresponding to CPARTID) and RMID (Resource Monitor ID, corresponding
to the (MPARTID, PMG) pair).


In the end, the number of control groups is determined by the number of
CPARTIDs. Both of these ID translation schemes support multiple control
groups.

Could you please help outline the pros and cons of each approach?
This will determine which direction I take for subsequent iterations.

Thanks in advance.


Best Regards,
Zeng Heng