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

[Babu Moger]

Hi Reinette,

On 9/16/26 09:42, Reinette Chatre wrote:
> Hi Babu,
>
> On 9/15/26 12:59 PM, Babu Moger wrote:
> > On 9/14/26 20:11, Moger, Babu wrote:
> > > On 9/14/2026 4:31 PM, Reinette Chatre wrote:
> > > > 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
>
> This would demonstrate how the change impacts pqos. Since the spirit of the
> changelog continues to be "resctrl should not break pqos" it should motivate
> why incorrect wraparound like above is more acceptable than returning 0 MB/s
> when counters are not assigned.

Will do.
Thanks
Babu