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

[Babu Moger <babu.moger@amd.com>]

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