Re: [PATCH 1/2] x86/resctrl, Documentation: Keep mbm_assign_mode "default" on boot

[Borislav Petkov]

On Tue, Jul 28, 2026 at 05:20:54PM -0500, Moger, Babu wrote:
> Hi Reinette,
> 
> On 7/28/2026 4:58 PM, Reinette Chatre wrote:
> > Hi Babu,
> > 
> > On 7/28/26 1:43 PM, Babu Moger wrote:
> > > Hi Tony,
> > > 
> > > On 7/28/26 15:24, Luck, Tony wrote:
> > > > > > 1) Does it start over from zero?
> > > > > >       Seems a sane option.
> > > > > > 2) Or does the monitor group see whatever the counter was at
> > > > > > when being used by some other group?
> > > > > >       Seems less sane.
> > > > > 
> > > > > As per this code, it should start over from 0.
> > > > > 
> > > > >     } else if (ret == -EINVAL) {
> > > > >                    am = get_arch_mbm_state(hw_dom, rmid, eventid);
> > > > >                    if (am)
> > > > >                            am->prev_msr = 0;
> > > > >            }
> > > > 
> > > > Nope. If you want the value reported to the user to start over from zero,
> > > > then prev_msr should be set to the current value of the counter. That
> > > > would make the next read start from zero.
> > > > 
> > > When an RMID is reallocated, the hardware detects the state
> > > transition and the first read returns "Unavailable". At that point,
> > > the counter is reset and begins counting again from 0. This is the
> > > expected behavior on AMD systems. Therefore, setting prev_msr to 0
> > > is the correct behavior.
> > 
> > I believe Tony was curious how this looks from the user's perspective.
> > 
> > > From what I understand it is neither of the presented options but instead:
> > 
> > 3) Internal cache of hardware counter (prev_msr) is reset when resctrl discovers
> >     that the underlying counter has been re-assigned.
> >     There is a separate software maintained cumulative count to which the
> >     hardware counter value is added as the event is tracked. This cumulative
> >     count is the value returned to the user.
> >     The user thus always sees that the event count increase and it is
> >     guaranteed to only increase based on a portion of memory bandwidth
> >     consumed by the RMID/event being tracked.
> >     The returned (cumulative) count will not be accurate if the underlying
> >     counter was re-assigned. The user does not have insight into how long the
> >     underlying counter(s) was assigned to the event being counted.
> 
> Agreed. When this happens, the counters will not be accurate.

So, to summarize the situation so far (and all y'all, I'd like you to please
only reply to the questions I'm asking. Babu, please do not try to summarize
it for me - that's what I'm trying to do now.)

So:

Background
----------

On AMD, ABMC (Assignable Bandwidth Monitoring Counters) mode is enabled by
default on machines that support it. Some systems can have 32 or less
counters.

The old default measurement mode uses RMIDs (4096 available in total) and the
hardware can track 64 RMIDs concurrently.

Problem
-------

In some cases, all ABMC counters can be consumed, leading to counter
exhaustion and tools like pqos reporting zero bandwidth for the groups
suffering exhaustion. It is important to note that in ABMC mode, two counters
per monitor group are used: one for local MBM and one for total MBM.

In contrast to the old default option, the ABMC option which is the default
now, is only half the counters so the exhaustion can happen faster/easier now.

Is that an accurate initial summary so far?

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette