Re: [PATCH 1/2] x86/resctrl, Documentation: Keep mbm_assign_mode "default" on boot

[Reinette Chatre]

Hi Boris and Babu,

On 7/27/26 7:05 AM, Borislav Petkov wrote:
> On Fri, Jul 24, 2026 at 04:53:26PM -0700, Reinette Chatre wrote:
>> One clarification here is that as I understand there has not yet been
>> an actual user complaint. At least not that the pqos utility mentioned in
>> this thread is aware of. Instead I struggle with the speculation about possible
>> user complaints with different interpretations on how this change could be
>> perceived by users. 
> 
> Sure, but don't you think that it is enough that we know about it?

Only if we are sure that we have the complete picture. I do not believe we do, yet.

I connected with the friendly pqos folks on this issue. They subsequently did an audit of
the tool to understand how it may behave under the different scenarios. They found that
the tool currently parses text return values ("Unavailable", "Unassigned") as zero.
This could cause incorrect behavior. (more below)

> 
> I mean, the pqos tool shows 0.0 in the MBL/MBR columns now.
> 
> And is the 
> 
>   pqos -m all:[0-191]
> 
> invocation not something people would usually run?

ABMC enabled (mode claimed to be incompatible with pqos)
--------------------------------------------------------
This example is from Babu's email that highlights that when ABMC is enabled this returns
zero as bandwidth from pqos perspective. This matches the pqos audit that found with text return
states, like the "Unassigned" happening underneath the output above, the return value is zero. When
the counters are not assigned then the events will always return "Unassigned" (until reassigned)
so having it return zero all the time may not cause issues. Once reassigned the event value
will always return a valid value (no text return values).

ABMC disabled (mode claimed to be compatible with pqos)
-------------------------------------------------------
Without ABMC there are scenarios when events may return "Unavailable". These scenarios vary
based on how many monitor groups are created and the workloads run. I am not able to test this
but when I attempt to combine what I know about AMD bandwidth monitoring with the results from
the pqos audit I am concerned that there may be a problem.

Consider a scenario where an event may return "Unavailable", for example:

<return A>, <return "Unavailable">, <return B (larger than A)>, <return "Unavailable">, ...

pqos will see:
A, 0, B, 0, ...

The "pqos -m" usage attempts to determine the bandwidth rate and, for example, when going from
"A" to "0" it will be considered counter wraparound that would appear as a very large and
wrong bandwidth number.


Question to Babu
----------------
Do you perhaps have a test/workloads that, under "default" counter assignment mode, can create
many monitor groups (more than 64) and cause "Unavailable" to be returned frequently? Would it
be possible to put pqos through its paces in this environment?

Of course, "AMBC disabled" scenario also includes AMD systems before ABMC was introduced. I do
not know why the issue with "Unavailable" handling (text returns in general) has not been reported
until now. I assume the pqos team may do most testing on Intel systems that do not return text.

>> When considering a change like this, should it be a stable candidate to
>> help reduce the number of kernels with different behaviors?
> 
> Yeah. It needs to be minimal too for easier backporting.

ack.

> 
>> The patch notes mention that this change is planned to be reverted at some
>> point in the future and I have not heard of any changes to this plan.
> 
> Where does it say that? I don't see that aspect.

For convenience, copy of patch notes from original commit [1] is below:

	There are plans to enable "mbm_event" by default once additional counters
	are available. For now, keep the default mode to maintain compatibility
	with existing tools.

Reinette

[1] https://lore.kernel.org/lkml/8cb66e18e32e4087a9712c1e68ee6da614efe244.1784322818.git.babu.moger@xxxxxxx/