Re: [PATCH v2 3/3] x86/resctrl: Keep mbm_assign_mode in default mode at boot

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

Hi Reinette,

On 9/16/26 09:42, Reinette Chatre wrote:
> Hi Babu,
> 
> On 9/15/26 12:59 PM, Babu Moger wrote:
>> On 9/14/26 20:11, Moger, Babu wrote:
>>> On 9/14/2026 4:31 PM, Reinette Chatre wrote:
>>>> On 9/14/26 1:45 PM, Babu Moger wrote:
>>>>> On 9/11/26 17:25, Reinette Chatre wrote:
>>>>>> On 9/4/26 11:06 AM, Babu Moger wrote:
>>>>
>>>> ...>>> systems with limited MBM counters and breaks existing userspace that
>>>>>>> assumes the historical default mode, including the pqos tool from
>>>>>>> intel-cmt-cat [1].
>>>>>>
>>>>>> There is no record of this breaking pqos. *you* created [1] *after* you
>>>>>> submitted v1. What a strategy! I mentioned a couple of times that this is
>>>>>
>>>>> Agreed.
>>>>>
>>>>>> misleading. Since you insist on proclaiming "we cannot break pqos!" as
>>>>>> motivation for this change you have to also disclose the consequence of
>>>>>> this change on pqos followed by motivation why that is acceptable. Specifically:
>>>>>>
>>>>>>       https://lore.kernel.org/lkml/77f77d02-fae7-401d-9bb5- c62b244d23cd@intel.com/
>>>>>
>>>>> I can provide output that demonstrates the issue, where the event counters report zeros. However, we won't observe the large counter values because the hardware resets the counters after reallocation.
>>>>>
>>>>> Will that be ok?
>>>>
>>>> No. This is not about hardware resetting the counters. This is about pqos not handling
>>>> text return values, for example "Unavailable" and "Unassigned". This patch only
>>>> focuses on pqos treating "Unassigned" as 0, but in "default" mode "Unavailable" will
>>>> be encountered and pqos treating it as 0 is more severe.
>>>>
>>>> Consider a scenario where a counter is re-assigned. When user space reads the event
>>>> value then it may see:
>>>>
>>>> <return A>, <return "Unavailable">, <return B (larger than A)>, <return "Unavailable">, ...
>>>>
>>>> "B" is computed by adding the new hardware counter value to A. As you indicate, hardware
>>>> did reset the counter after re-allocation but that only means that "B" is no longer
>>>> accurate. "B" is still returned and it is still larger than "A".
>>>>
>>>> Based on above, pqos sees:
>>>> A, 0, B, 0, ...
>>>>
>>>> These jumps between bandwidth counts and zero is what pqos perceives as wraparound that is
>>>> presented in the example:
>>>>
>>>>      https://lore.kernel.org/lkml/77f77d02-fae7-401d-9bb5- c62b244d23cd@intel.com/
>>>
>>> Got it. I can add the output of the issue. Something like this.
>>>
>>> TIME 2026-09-15 00:53:46
>>> CORE     IPC      MISSES     LLC[KB]   MBL[MB/s]   MBR[MB/s]
>>> 0        0.76         60k        32.0         0.0         0.0
>>> 1        0.45          1k        32.0         0.0         0.0
>>> 2        1.57        107k        64.0         0.0 17592186044184.9
>>> 3        1.62        276k      4928.0         3.2         0.5
>>> 4        0.53          1k       160.0         0.0         0.0
>>> 5        0.63         39k      1664.0         0.2         0.0
>>> 6        0.44          6k       128.0         0.0         0.0
>>> 7        0.50          1k       320.0         0.0         0.0
> 
> This would demonstrate how the change impacts pqos. Since the spirit of the
> changelog continues to be "resctrl should not break pqos" it should motivate
> why incorrect wraparound like above is more acceptable than returning 0 MB/s
> when counters are not assigned.

Will do.
Thanks
Babu