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

[Luck, Tony]

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.

> 
> 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.

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.

> 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
> 

-Tony