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

[Moger, Babu]

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

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