[PATCH v8 next 02/10] arm_mpam: Add intPARTID and reqPARTID support for Narrow-PARTID feature

[Zeng Heng]

Hi James,


On 2026/5/15 1:06, James Morse wrote:
> Hi Zeng,
> 
> On 13/04/2026 09:53, Zeng Heng wrote:
>> Introduce Narrow-PARTID (partid_nrw) feature support, which enables
>> many-to-one mapping of request PARTIDs (reqPARTID) to internal PARTIDs
>> (intPARTID). This expands monitoring capability by allowing a single
>> control group to track more task types through multiple reqPARTIDs
>> per intPARTID, bypassing the PMG limit in some extent.
>>
>> intPARTID: Internal PARTID used for control group configuration.
>> Configurations are synchronized to all reqPARTIDs mapped to the same
>> intPARTID. Count is indicated by MPAMF_PARTID_NRW_IDR.INTPARTID_MAX, or
>> defaults to PARTID count if Narrow-PARTID is unsupported.
>>
>> reqPARTID: Request PARTID used to expand monitoring groups. Enables
>> a single control group to monitor more task types by multiple reqPARTIDs
>> within one intPARTID, overcoming the PMG count limitation.
>>
>> 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.
>>
>> So, the numbers of control group and monitoring group are calculated as:
>>
>>    n = min(intPARTID, PARTID)  /* the number of control groups */
>>    l = min(reqPARTID, PARTID)  /* the number of monitoring groups */
>>    m = l // n                  /* monitoring groups per control group */
>>
>> Where:
>>
>>    intPARTID: intPARTIDs on Narrow-PARTID-capable MSCs
>>    reqPARTID: reqPARTIDs on Narrow-PARTID-capable MSCs
>>    PARTID:    PARTIDs on non-Narrow-PARTID-capable MSCs
>>
>> Example: L3 cache (256 PARTIDs, without Narrow-PARTID feature) +
>>           MATA (32 intPARTIDs, 256 reqPARTIDs):
>>
>>    n = min( 32, 256) =  32 intPARTIDs
>>    l = min(256, 256) = 256 reqPARTIDs
>>    m = 256 / 32 = 8 reqPARTIDs per intPARTID
>>
>> Implementation notes:
>>    * Handle mixed MSC systems (some support Narrow-PARTID, some don't) by
>>      taking minimum number of intPARTIDs across all MSCs.
>>    * resctrl_arch_get_num_closid() now returns the number of intPARTIDs
>>      (was PARTID).
> 
> What you're doing here is making intPARTID the fundamental unit in MPAM. I
> don't think we should do this as its not true in the architecture: narrowing
> is a single, optional feature. We have platforms that don't support narrowing
> at all - so having to think in terms of "what is the intPARTID limit on this
> platform that doesn't have the feature" is confusing.
> Narrowing doesn't affect the monitoring, so you can't just string-replace the
> driver.
> 
> The resctrl glue code is going to have to know about narrowing as it must
> either duplicate the control values for aliasing PARTID, or remap them using
> narrowing.
> 
> I'd prefer it if the mpam_devices code exposed an API to make use of narrowing
> that makes sense given the MPAM architecture. (e.g. narrowing is optional!)
> Whetever resctrl needs should then be built on top of that.
> 
> 
> Currently the MAX PARTID/PMG are dealt with separately as we need a global value
> at the end. It was done separately as it could be a patch on its own, to try and
> keep each patch reviewable.
> But it should probably have been dealt with the same way we deal with all MSC
> features - stash them in struct mpam_msc_ris at hw_probe time, and combine them
> up to the class level handling different values with __props_mismatch().
> The global state that includes the requestors can be created after that point.
> 
> I think we should do this now to add intpartid_max to struct mpam_props so that the
> resctrl glue code can find the intpartid_max per class. I don't think it makes sense as
> a global property. (we should move partid_max and pmg_max at the same time)
> 
> ... I think moving partid_max would just be cleanup. The resctrl glue code needs to
> know the maximum PARTID for monitoring, but I think this would always be the global
> PARTID max value.
> 

I'll have a try to look into refactoring the existing code along the
lines you've suggested.


> 
>> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
>> index 41b14344b16f..cf067bf5092e 100644
>> --- a/drivers/resctrl/mpam_devices.c
>> +++ b/drivers/resctrl/mpam_devices.c
>> @@ -63,6 +63,7 @@ static DEFINE_MUTEX(mpam_cpuhp_state_lock);
>>    * Generating traffic outside this range will result in screaming interrupts.
>>    */
>>   u16 mpam_partid_max;
>> +u16 mpam_intpartid_max;
>>   u8 mpam_pmg_max;
>>   static bool partid_max_init, partid_max_published;
>>   static DEFINE_SPINLOCK(partid_max_lock);
> 
> The global properties are supposed to mean "if you generate any traffic outside
> this range, you'll get an out of range error causing mpam_disable()".
> 
> This doesn't hold for intPARTID.
> 
> In my hypothetical system from the cover letter: {
>    64 PARTID at the L3
>    64 PARTID and narrowing to 16 at the SLC
>    64 PARTID and narrowing to 32 at the memory-controller
> 
>    The resctrl glue code could ignore the SLC if it wanted to use 32 PARTID, and just
>    duplicate the aliasing controls at L3. (and remove the non-aliasing controls)
> }
> 
> 

Thanks for the example.


Best regards,
Zeng Heng