Re: [PATCH v3 3/3] x86,fs/resctrl: Keep mbm_assign_mode in default mode at boot

[Moger, Babu]

Hi Reinette,

On 10/7/2026 5:21 PM, Reinette Chatre wrote:
> Hi Babu,
>
> On 10/7/26 11:54 AM, Babu Moger wrote:
> > On 10/6/26 12:53, Reinette Chatre wrote:
> > > On 10/2/26 2:26 PM, Babu Moger wrote:
> ...
> > > > workflows that monitor a subset of groups at a time and rotate
> > > > assignments as needed.
> > > >
> > > > resctrl enables the "mbm_event" mode by default on hardware that
> > > > supports it. That breaks the pqos tool [1], which assumes the historical
> > > > default mode. pqos treats a non-numeric event read as zero bandwidth. It
> > > > creates 16 or more monitoring groups and uses two counters per group.
> > > > On a platform with 32 counters per domain, that consumes the pool, so
> > > > further groups read "Unassigned" and pqos reports 0 MB/s for them:
> > > >
> > > >     $sudo pqos -m all:0-4
> > > >     CORE         IPC      MISSES     LLC[KB]   MBL[MB/s]   MBR[MB/s]
> > > >        0        0.69         16k       192.0         0.0         0.0
> > > >        1        0.40          3k         0.0         0.0         0.0
> > > >        2        0.44          1k        64.0         0.0         0.0
> > > >        3        0.39          1k        64.0         0.0         0.0
> > > >        4        0.43          1k         0.0         0.0         0.0
> > > >
> > > > Leave mbm_assign_mode in "default" mode during initialization. Default
> > > > mode uses one counter per monitoring group. On existing AMD platforms
> > > > that pool is 64 counters and may be larger on newer hardware. The
> > > > "mbm_event" mode uses two counters per group, so 32 counters cover only
> > > > 16 groups.
> > > >
> > > > Deployments within that pool receive accurate bandwidth measurements
> > > > with default mode. The hardware supports 4096 monitoring groups. Beyond
> > > > that pool, readings may be misleading or "Unavailable", with no
> > >
> > > At this point I am lost because the word "pool" is used to mean three
> > > different things. It is used for the number of "ABMC counters" as well
> > > as the number of "non-ABMC counters" that exist on the same platform,
> > > above it seems to be used for number of RMIDs (number of monitoring
> > > groups) also. Could you please add some context at beginning of
> > > changelog to introduce the various counts applicable to the description,
> > > associate unique terms to these counts at that time, and then use
> > > those unique terms in the rest of the changelog?
> >
> > Sure.
> > I can name as "ABMC counters pool" and "default active counters pool"
>
> hmmm ... "active counter" is new term that, when grepping this series,
> fs/resctrl/*, and arch/x86/kernel/cpu/resctrl/*, does not appear a single
> time.
> If this new term is needed then please include a definition as part of the
> changelog context that makes it obvious what it refers to.

Sure. Will do.
Thanks
Babu