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

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

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