Re: [PATCH v1 1/4] x86,fs/resctrl: Make resctrl_arch_is_evt_configurable() aware of mbm_assign_mode

[Ben Horgan]

Hi Reinette,

On Mon, Mar 02, 2026 at 03:11:48PM -0800, Reinette Chatre wrote:
> Hi Ben,
> 
> On 2/25/26 12:19 PM, Ben Horgan wrote:
> > The features BMEC and ABMC provide separate interfaces to configuring which
> > bandwidth types a counter tracks. Currently
> > resctrl_arch_is_evt_configurable() only ever returns true if BMEC is
> > supported.
> > 
> > ABMC is useful even when BMEC is supported as it also provides counter
> > assignment which reduces the number of hardware monitors a system
> > requires. It is an architectural detail that ABMC provides counter
> 
> Since the goal is to support MPAM I'd suggest that the first focus be on what
> resctrl fs supports and exposes and how it does or does not work for MPAM.
> 
> > configurability without requiring the prior feature, BMEC. On MPAM systems
> > these two features are independent and the bandwidth types are limited to a
> > choice of only read or write.
> 
> Does MPAM support exactly these two features? Specifically, does MPAM support
> a feature that allows user to configure events globally per domain and another
> feature that allows user to configure events per PMG?

No, the bandwidth type configuration in MPAM is per counter and so effectively
per (PARTID, PMG) pair. In supporting hardware, the configuration is made in the
RWBW field of MSMON_CFG_MBWU_FLT and allows counting of just read, just write,
or both.

> 
> These different features are how I understand assignable counters and BMEC to

We are each approaching this from a different view point. I've just been looking at
ABMC as a way of dealing with systems where there are fewer hardware counters than
(PARTID, PMG) pairs (num_rmid) by requiring a counter to be assigned to a
CTRL_MON or MON group in order to be usable. resctrl otherwise expects a counter
per CTRL_MON/MON group. Sharing bandwidth counters doesn't work
as they need a fixed (PARTID, PMG) configuration to avoid missing counts.

The intent of this patch is to allow splitting these two features of ABMC,
bandwidth type configuration and hardware counter assignment in order to just
support the hardware counter assignment.

I'm still not understanding the distinction you are making though.
The files are,
With ABMC:
info/L3_MON/event_configs/mbm_[local,total]_bytes/event_filter
and with BMEC they are:
info/L3_MON/mbm_[local,total]_bytes_config

In both cases they have allow configuration for two event types,
mbm_local_bytes, and mbm_total_bytes. What am I missing?

> be and to support both at the same time requires a user interface that is
> confusing since the user can concurrently configure events globally per-domain
> and per resource group.

Sure.

> 
> Could you please elaborate how event configuration work on MPAM? If find this
> series quite cryptic. I think it will help if you could elaborate what MPAM
> capabilities are and how you expect resctrl fs to expose these features to
> an MPAM user and how said used is expected to interact with resctrl fs to use
> the features.

Ok, firstly regarding hardware counter assignment, on MPAM systems with more
(PARTID, PMG) pairs than bandwidth hardware counters we'd like to expose the
mbm_L3_assignments for tracking which CTRL_MON/MON groups have bandwidth
counting events and otherwise not.

I haven't put much thought into how we would support event configuration with
MPAM but we would want something that allows the configuration per hardware
counter or (PARTID, PMG) pair. I'd rather not commit to the existing interface
as this looks to commit us to per event type configuration. Please correct me
if this isn't the case.

> 
> > 
> > In order to give resctrl the information to support these features
> > independently extend resctrl_arch_is_evt_configurable() to report whether
> > events are configurable when using the mbm_event counter assignment mode.
> > 
> > Signed-off-by: Ben Horgan <ben.horgan@xxxxxxx>
> > ---
> >  arch/x86/kernel/cpu/resctrl/core.c | 12 ++++++++++--
> >  fs/resctrl/monitor.c               |  4 ++--
> >  include/linux/resctrl.h            |  2 +-
> >  3 files changed, 13 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
> > index 7667cf7c4e94..d35f4417d55e 100644
> > --- a/arch/x86/kernel/cpu/resctrl/core.c
> > +++ b/arch/x86/kernel/cpu/resctrl/core.c
> > @@ -877,11 +877,19 @@ bool rdt_cpu_has(int flag)
> >  	return ret;
> >  }
> >  
> > -bool resctrl_arch_is_evt_configurable(enum resctrl_event_id evt)
> > +bool resctrl_arch_is_evt_configurable(enum resctrl_event_id evt, bool assignable)
> >  {
> > -	if (!rdt_cpu_has(X86_FEATURE_BMEC))
> > +	if (!assignable && !rdt_cpu_has(X86_FEATURE_BMEC))
> >  		return false;
> >  
> > +	if (assignable && !rdt_cpu_has(X86_FEATURE_ABMC))
> > +		return false;
> > +
> 
> I find this very confusing. 
> 
> > +	/*
> > +	 * When ABMC is used the mbm_local and mbm_total events are enabled
> > +	 * based on the equivalently named cpu features. (In order to allow
> > +	 * fallback to the default counter assignment mode).
> > +	 */
> >  	switch (evt) {
> >  	case QOS_L3_MBM_TOTAL_EVENT_ID:
> >  		return rdt_cpu_has(X86_FEATURE_CQM_MBM_TOTAL);
> 
> 
> Reinette

Thanks,

Ben