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

[Reinette Chatre <reinette.chatre@intel.com>]

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.

...

>>>>> Although, the earlier text is "up to 64" so above attempt at guidance may not
>>>>> be correct and there is no knowing how many monitoring groups are guaranteed
>>>>> to receive accurate counts?
>>>>
>>>> That is correct. We can get this count by assigning counters
>>>> iteratively until an "unavailable" response is returned. However,
>>>> the specification does not mention this behavior.
>>>
>>> This is about determining the "magic" number of RMIDs, not about counter assignment.
>>> User space does not do any counter assignment here. In this case user space can create
>>> monitoring groups up to the maximum number of RMIDs supported.
>>
>> Little bit confused here. How about we revisit this text again in v3?

Sure.

>>>
>>> This would only be useful if all hardware support the same number of magic RMID though.
>>
>> It
> 
> Sorry. Response cut short.
> 
> How about we revisit in v3?
Sure.

Reinette