[PATCH v8 next 03/10] arm_mpam: Disable reqPARTID expansion when Narrow-PARTID is unavailable

[Zeng Heng]

Hi James,

On 2026/5/15 1:06, James Morse wrote:
> Hi Zeng,
> 
> On 13/04/2026 09:53, Zeng Heng wrote:
>> MPAM supports heterogeneous systems where some type of MSCs may implement
>> Narrow-PARTID while others do not. However, when an MSC uses
>> percentage-based throttling (non-bitmap partition control) and lacks
>> Narrow-PARTID support, resctrl cannot correctly apply control group
>> configurations across multiple PARTIDs.
>>
>> To enable free assignment of multiple reqPARTIDs to resource control
>> groups, all MSCs used by resctrl must either: Implement Narrow-PARTID,
>> allowing explicit PARTID remapping, or only have stateless resource
>> controls (non-percentage-based), such that splitting a control group
>> across multiple PARTIDs does not affect behavior.
> 
> I prefer Dave's terminology for this: aliasing and non-aliasing. It implies
> there are two controls, which stateless does not.
> 

OK, count me as a fan of the terminology too.

> 
>> The detection occurs at initialization time on the first call to
>> get_num_reqpartid() from update_rmid_limits(). This call is guaranteed
>> to occur after mpam_resctrl_pick_{mba,caches}() have set up the
>> resource classes, ensuring the necessary properties are available
>> for the Narrow-PARTID capability check.
>>
>> When an MSC with percentage-based control lacks Narrow-PARTID support,
>> get_num_reqpartid() falls back to returning the number of intPARTIDs,
>> effectively disabling the reqPARTID expansion for monitoring groups.
> 
> No MSC has percentage based controls - that's an x86ism. The MSCs have
> fixed point fractions, bitmaps or a cost/weight.
> 

Yes, thanks for head-up: it's x86ism.

> 
> I think you're thinking about this the wrong way up - we should only enable
> this on a small number of platforms that don't have any controls we'd have to discard.
> (hopefully yours is such a platform!)
> 
> I don't think this should be added to resctrl_arch_system_num_rmid_idx(). Please make
> this decision for resctrl at mpam_resctrl_setup() time.
> 
> 
>> diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
>> index 5f4364c8101a..56859f354efa 100644
>> --- a/drivers/resctrl/mpam_resctrl.c
>> +++ b/drivers/resctrl/mpam_resctrl.c
>> @@ -257,9 +257,50 @@ u32 resctrl_arch_get_num_closid(struct rdt_resource *ignored)
>>   	return mpam_intpartid_max + 1;
>>   }
>>   
>> +/*
>> + * Determine the effective number of PARTIDs available for resctrl.
>> + *
>> + * This function performs a one-time check to determine if Narrow-PARTID
>> + * can be used. It must be called after mpam_resctrl_pick_{mba,caches}()
>> + * have initialized the resource classes, as class properties are used
>> + * to detect Narrow-PARTID support.
> 
>> + * The first call occurs in update_rmid_limits(), ensuring the
>> + * prerequisite initialization is complete.
> 
> This is fragile to changes in the order resctrl makes these calls. We need these
> properties to be fixed before we call resctrl_init().
> 
> (yes - I think CDP is fragile too!)

It makes sense to me.

> 
> 
>> + */
>> +static u32 get_num_reqpartid(void)
>> +{
>> +	struct mpam_resctrl_res *res;
>> +	struct mpam_props *cprops;
>> +	static bool first = true;
>> +	int rid;
>> +
>> +	if (first) {
>> +		for_each_mpam_resctrl_control(res, rid) {
>> +			if (!res->class)
>> +				continue;
>> +
>> +			cprops = &res->class->props;
>> +			if (mpam_has_feature(mpam_feat_partid_nrw, cprops))
>> +				continue;
> 
> 
>> +			if (mpam_has_feature(mpam_feat_mbw_max, cprops) ||
>> +			    mpam_has_feature(mpam_feat_mbw_min, cprops) ||
>> +			    mpam_has_feature(mpam_feat_cmax_cmax, cprops) ||
>> +			    mpam_has_feature(mpam_feat_cmax_cmin, cprops)) {
> 
> Please make this a helper in mpam_internal.h with 'controls' and 'aliasing' in its name.
> (maybe has_aliasing_controls()).
> 
> What about the priority for PRI and the proportional-stride?
> 
> I don't think proportional-stride aliases properly: if I have groups with stride 1 and 2,
> I can't add a second '2' without decreasing the first groups stride from 1/3 to 1/5. If I
> halve the second groups, they each get half the bandwidth instead of sharing it.
> 
> Can you check whether the priority for PRI aliases?
> 

Proportional-stride is indeed a non-aliasing control, and this was an
oversight on my part (I haven't actually encountered this control option
before).

I'd argue that PRI is an aliasing control: the priority value defines a
scheduling class or identity. When multiple PARTIDs share the same
priority, it's akin to multiple users holding the same VIP tier. They
compete for resources within that same category, rather than each
receiving an independent, additive allocation.


Best regards,
Zeng Heng