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/14/26 20:11, Moger, Babu wrote:
> Hi Reinette,
> 
> On 9/14/2026 4:31 PM, Reinette Chatre wrote:
>> Hi Babu,
>>
>> 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
> 
> 
>>
>>>>> For example, pqos mounts resctrl and creates 16 or more monitoring 
>>>>> groups,
>>>>> using two counters per group (mbm_local_bytes and mbm_total_bytes). On
>>>>> platforms that provide 32 MBM counters per domain, this consumes 
>>>>> the entire
>>>>> counter pool. Additional groups cannot be assigned counters and pqos
>>>>> reports zero bandwidth for them.
>>>>>
>>>>> Leave mbm_assign_mode in "default" mode during initialization. 
>>>>> Default mode
>>>>> can support more monitoring groups (up to 64) than mbm_event mode, 
>>>>> which is
>>>>
>>>> "up to 64" - so it may be fewer than 64? What is guidance to users 
>>>> about
>>>> how many monitoring groups in "default" mode are "safe"?
>>>
>>> It is 64. It be more on newer h/w (don't know exact count).
>>
>> Should it then read "64 or more" instead of "up to 64"?
> 
> Sure.
> 
>>
>> ...
>>
>>>>
>>>> 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?
> 
>>
>> ...
>>
>>>
>>>>
>>>>> +    remain accurate. Creating more groups than that pool (for 
>>>>> example 64 or
>>>>
>>>> "64" -> "65"?
>>>
>>> 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?

Thanks
Babu