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

[Reinette Chatre]

Hi Tony,

On 9/14/26 4:21 PM, Luck, Tony wrote:
> On Mon, Sep 14, 2026 at 03:03:45PM -0700, Reinette Chatre wrote:
>> 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.
> 
> Perhaps I need to be clear on what "system maximum" means here. See below.
> 
>>>>
>>>> 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.
> 
> So if L3_MON does not exist (because L3 monitoring has been disabled) then
> the user will expect to be able to create info/PERF_PKG_MON/num_rmids MON
> directories. So that number must not be more than what can legally be
> written to IA32_PQR_ASSOC.RMID.

ack, and info/PERF_PKG_MON/num_rmids is the same whether L3_MON exists or not?

> 
>>
>> 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.
> 
> To clarify, I am not proposing on limiting PERF_PKG_MON to whatever
> limit L3 has. I'm proposing limiting it to (CPUID(0xF,0x0).EBX + 1).
> That's the "system maximum" in this context.

ah, ok, sounds good. I was considering the resctrl_arch_system_max_rmid_idx()
as called in this patch that incorporates the L3 limit.

> The L3 limit could be lower than that, or may have been reduced if Sub-NUMA
> Cluster is enabled. I don't want to use that value.

ok sounds good.

Could this restriction perhaps be contained during AET enumeration where
event_group::num_rmid is initialized (currently enable_events())?

Reinette