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

[Moger, Babu]

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.

Thanks
Babu