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

[Shaopeng Tan (Fujitsu)]

Hello Zeng,

> 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.

I think the fundamental difference between these two approaches 
lies in whether the  allocation is static or dynamic. 
I proposed a similar idea to James and Dave about two years ago.
I agree that your proposal for dynamic allocation is excellent
in terms of flexibility and resource utilization.

However, dynamically assigning MPARTID_hi and MPARTID_lo upon 
the creation or deletion of a control/monitoring group would likely 
require extensive modifications to the resctrl core code.
In particular, with the integration of PARTID Narrowing occurring 
alongside major changes to the resctrl interface, 
there is a risk that these modifications might interfere with
each other and lead to complications.

To ensure a smooth and timely merge, would it be better to proceed
in stages - first implementing static allocation and then 
transitioning to dynamic allocation afterward? 
What do you think?

Best regards,
Shaopeng TAN