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

[Shaopeng Tan (Fujitsu)]

Hello Zeng Heng,

> 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.
> 
> 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.
> 
> 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
> --------------------------------------------------------------------------
> 
> Under MPAM, the number of reqPARTID is always greater than or equal to
> intPARTID.

If reqPARTID % intPARTID > 0, does that mean we cann’t fully use reqPARTIDs?
Some chips have a large number of intPARTIDs, is it possible to use only a limited number of intPARTIDs?

As you know, Arm (Dave) has also implemented the partid narrowing feature[1],
are there aspects of Arm's proposal that do not meet Huawei's requirements?
Also, could you tell me about your future plans?
https://lore.kernel.org/lkml/20250117151033.1517882-1-Dave.Martin@xxxxxxx/ [1]

Best regards,
Shaopeng TAN