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

["Moger, Babu" <bmoger@amd.com>]

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