Re: [PATCH v3 0/9] arm_mpam: Introduce Narrow-PARTID feature

[Ben Horgan]

Hi Zeng,

On 3/17/26 13:21, Zeng Heng wrote:
> This series applies on top of the mpam_resctrl_glue_v5_debugfs branch of:
> https://gitlab.arm.com/linux-arm/linux-bh.git
> 
> Background
> ==========
> 
> On x86, the resctrl allows creating up to num_rmids monitoring groups
> under parent control group. However, ARM64 MPAM is currently limited by
> the PMG (Performance Monitoring Group) count, which is typically much
> smaller than the theoretical RMID limit. This creates a significant
> scalability gap: users expecting fine-grained per-process or per-thread
> monitoring quickly exhaust the PMG space, even when plenty of reqPARTIDs
> remain available.
> 
> The Narrow-PARTID feature, defined in the ARM MPAM architecture,
> addresses this by associating reqPARTIDs with intPARTIDs through a
> programmable many-to-one mapping. This allows the kernel to present more
> logical monitoring contexts.

Thanks for this series and all your help with MPAM driver. Using PARTID
narrowing to allow more resctrl monitoring groups is a good idea.

> 
> Design Overview
> ===============
> 
> The implementation extends the RMID encoding to carry reqPARTID
> information:
> 
>   RMID = reqPARTID * NUM_PMG + PMG
> 
> In this patchset, a monitoring group is uniquely identified by the
> combination of reqPARTID and PMG. The closid is represented by intPARTID,
> which is exactly the original PARTID.
> 
> For systems with homogeneous MSCs (all supporting Narrow-PARTID), the
> driver exposes the full reqPARTID range directly. For heterogeneous
> systems where some MSCs lack Narrow-PARTID support, the driver utilizes
> PARTIDs beyond the intPARTID range as reqPARTIDs to expand monitoring
> capacity. The sole exception is when MBA MSCs lack Narrow-PARTID support,
> their percentage-based control mechanism prevents the use of PARTIDs as
> reqPARTIDs.

We also need to consider how this will interact with cache capacity controls
(CMAX/CMIN). Although, they are not exposed by the driver yet.

> 
> Capacity Improvements
> =====================
> 
> --------------------------------------------------------------------------
> The maximum        |  Sub-monitoring groups            | System-wide
> number of          |  under a control group            | monitoring groups
> --------------------------------------------------------------------------
> Without            |                                   |
> reqPARTID          |  PMG                              | intPARTID * PMG
> --------------------------------------------------------------------------
> reqPARTID          |                                   |
> static allocation  | (reqPARTID // intPARTID) * PMG    | reqPARTID * PMG
> --------------------------------------------------------------------------
> reqPARTID          |                                   |
> dynamic allocation | (reqPARTID − intPARTID + 1) * PMG | reqPARTID * PMG
> --------------------------------------------------------------------------

Does the quest for more monitoring groups stop here or do you see a usecase
for limiting the number of control groups to get more monitoring groups?

Thanks

Ben