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

[Babu Moger]

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

Sorry. Response cut short.

How about we revisit in v3?

Thanks
Babu