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

[Zeng Heng]

Hi Ben,

On 2026/3/21 0:14, Ben Horgan wrote:
> 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.

For MSRs that support percentage-based control mechanisms, if Narrow-
PARTID is not supported, the functionality needs to be rolled back.
The limitation will be included in the next version.


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

Plan to build upon the original patches by introducing an enhancement
that allows users to limit the number of control groups via a new boot
parameter, with a range of [1, intpartid], thereby achieving the goal of
expanding the number of monitoring groups.


Thanks for your review comments.


Best regards,
Zeng Heng