Re: [PATCH v10 08/17] x86/resctrl: Enforce system RMID limit on AET event groups
Reinette Chatre <[email protected]>
| Newsgroups | org.kernel.vger.linux-kernel,dev.linux.lists.patches |
|---|---|
| Message-ID | <[email protected]> |
Hi Tony, On 7/29/26 10:27 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. Especially true on systems with SNC (Sub-NUMA Cluster) > enabled as that reduces the number of supported RMIDs. > > Fix get_rdt_mon_resources() to return true when any monitor resource is hmmm ... "Fix" makes one look for the accompanying "Fixes:" tag. What is the fix here? What is wrong with existing implementation that needs fixing? To me this does not look like a fix though (more below). > possibly enabled. Call intel_aet_init() to adjust the event_group::num_rmid > values to not exceed the system supported maximum. Last sentence just documents the code. Please describe why this is needed. Is this a separate logical change? > > Signed-off-by: Tony Luck <[email protected]> > --- ... > diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c > index 092764cf693f..2c938b97b147 100644 > --- a/arch/x86/kernel/cpu/resctrl/core.c > +++ b/arch/x86/kernel/cpu/resctrl/core.c > @@ -1019,10 +1019,10 @@ static __init bool get_rdt_mon_resources(void) > if (rdt_cpu_has(X86_FEATURE_ABMC)) > ret = true; > > - if (!ret) > - return false; > + if (ret) > + rdt_get_l3_mon_config(r); > > - return !rdt_get_l3_mon_config(r); > + return boot_cpu_data.x86_cache_max_rmid > 0; > } From what I can tell this will return true when the system supports monitoring, but no resource may actually have monitoring enabled at this point. Specifically, no resource has rdt_resource::mon_capable set. The resctrl initialization now proceeds where it used to stop. resctrl_arch_late_init() will proceed and initialize the resctrl filesystem, which in turn would allow user space to mount it. rdt_get_tree() handling the user mount request could thus be run on a system that does not have a monitoring or allocation capable resource and then we see in rdt_get_tree(): if (resctrl_arch_alloc_capable() || resctrl_arch_mon_capable()) resctrl_mounted = true; The above flow change would cause resctrl to think the system supports monitoring but resctrl_arch_mon_capable() returns false. If there are no allocation features then this will result in resctrl fs mounted ... but resctrl_mounted is not set to true and thus allow a remount that is not supported. Reinette