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

[Babu Moger]

Hi Tony,

On 7/28/26 14:58, Luck, Tony wrote:
> > ABMC mode (also referred to as mbm_event mode) relies on ABMC counters,
> > and this system provides only 32 such counters.
> >
> > By comparison, the default mode uses RMIDs, with up to 4096 RMIDs
> > available. However, even though the RMID space is much larger, the
> > hardware can track only 64 RMIDs concurrently. As a result, if pqos
> > attempts to monitor more than 64 groups, the reported bandwidth
> > measurements may become inaccurate.
> >
> > That said, I have not been able to reproduce any bandwidth inaccuracies
> > on the systems I tested. My point is that this may not be a significant
> > issue for the vast majority of users
>
> How did you try to reproduce? It seems that it should be trivial to create
> more than 64 monitor groups with active tasks assigned to each group.
> That ought to show the issue quickly.

I started "pqos -m" to create 256 monitoring threads. It did not happen 
in this case.

Reinette has already instrumented the kernel to force the issue. So, we 
know the issue can happen.


> What does happen when I'm reading the memory bandwidth from a
> monitor group and the underlying counter for that RMID is stolen for
> use by another group, and then later this group steals a counter from
> someone else?
>
> I'm expecting "Unavailable" while there is no counter. But I'm not sure
> what happens when a counter is reacquired.
>
> 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;
        }

Thanks
Babu