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

[Reinette Chatre]

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@xxxxxxxxx/
> 
> 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@xxxxxxxxx/ 

>>> 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"?

...

>>
>> 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.

...

> 
>>
>>> +    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.

> 
>>
>>> +    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.

...

>>> @@ -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?

Reinette