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

[Babu Moger]

Hi Boris,

On 7/30/26 13:46, Borislav Petkov wrote:
> 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.

Therefore, creating more than 64 monitoring groups in the default 
measurement mode can lead to inaccurate measurement results.

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


Yes.

Thanks
Babu