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

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

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

> 
>>
>>>
>>>> +    more) can cause hardware to re-allocate counters
>>>> +    between reads. Bandwidth values may then be misleading, or reads may return
>>>
>>> "between reads" - what reads are referred to here?
>>
>> "between two event reads" ?
>>
> 
> This is unclear to me at this point.

Lets me revise the text an revisit.

> 
> ...
> 
>>>> @@ -474,8 +484,8 @@ with the following files:
>>>>          Determines if a counter will automatically be assigned to an RMID, MBM event
>>>>        pair when its associated monitor group is created via mkdir. Enabled by default
>>>> -    on boot, also when switched from "default" mode to "mbm_event" counter assignment
>>>> -    mode. Users can disable this capability by writing to the interface.
>>>> +    when switched to "mbm_event" counter assignment mode. Users can disable this
>>>
>>> Why is this change necessary? It seems to drop the text that mbm_assign_on_mkdir is
>>> enabled on boot ... but it is still enabled on boot, no?
>>
>> Yes. It is enabled on boot. It should not be set by default. Will update the patch.
> 
> This is about mbm_assign_on_mkdir that *is* set by default, on boot and when switching to
> "default" mode, no?

Yes. That is correct. This is about mbm_assign_on_mkdir.
Thanks
Babu