Re: [PATCH v11 14/23] x86/resctrl: Enforce system RMID limit on AET event groups

[Reinette Chatre]

Hi Tony,

On 9/14/26 2:33 PM, Luck, Tony wrote:
> On Wed, Sep 09, 2026 at 09:05:28PM -0700, Reinette Chatre wrote:
>> Hi Tony,
>>
>> On 8/31/26 10:44 AM, Tony Luck wrote:
>>> AET (Application Energy Telemetry) event groups each support a specific
>>> number of RMIDs. But that number may be lower than the number supported
>>> by the system. This is especially true on systems with SNC (Sub-NUMA Cluster)
>>> enabled as that reduces the number of supported RMIDs.
>>>
>>> Reduce all event_group::num_rmid to system maximum.
>>
>> Why is this needed? Doesn't resctrl_arch_system_num_rmid_idx() ensure the
>> minimum is taken across all resources? I do not see why a resource needs to
>> artificially reduce the number of RMIDs it supports.
> 
> rdt_resources_all[RDT_RESOURCE_PERF_PKG].r_resctrl.mon.num_rmid is used
> to display the value in /sys/fs/resctrl/info/PERF_PKG_MON/num_rmids.
> 
> It would cause confusion if a number > (CPUID(0xF,0x0).EBX + 1) appeared
> there.

That is fair, but on top of this this patch additionally reduces the number
of RMIDs of RDT_RESOURCE_PERF_PKG based on the number of RMID that RDT_RESOURCE_L3
supports.

Documentation has already been updated to contain:
	The upper bound for how many "CTRL_MON" + "MON" can be created
	is the smaller of the L3_MON and PERF_PKG_MON "num_rmids" values.

I do not see a reason for PERF_PKG_MON to pretend to support the same
number of RMIDs as L3. This unnecessarily hides information from user space.
A user may only be interested in PERF_PKG_MON and then see that mkdir of
monitoring directories fail before it reaches the supported num_rmids.
User interface will show that this is because of L3 and then user space will
know how many monitoring groups can be supported if/when L3 monitoring is
disabled. By pretending that both resources support the same number of
RMIDs this is not possible.

Reinette