Re: [PATCH 1/2] x86/resctrl, Documentation: Keep mbm_assign_mode "default" on boot
From: Moger, Babu
Date: Tue Aug 04 2026 - 19:44:48 EST
Hi Reinette,
On 8/4/2026 5:10 PM, Reinette Chatre wrote:
Hi Boris and Babu,
On 8/4/26 12:16 PM, Borislav Petkov wrote:
On Sat, Aug 01, 2026 at 04:47:01PM -0700, Reinette Chatre wrote:
...
On Intel the RMIDs are always counting. Please keep in mind that these RMID do not
actually return raw counts that are verbatim passed on to user space but instead
the returned value is "upscaled" using a hardware provided scaling factor to obtain the
value that is returned to user space. This is done on AMD (with and without ABMC)
and Intel.
So, long story short - and I appreciate the explaining - we should switch
AMD's default behavior back to RMID + 64 counters - exactly like it is on
Intel - and the ABMC thing will be explicitly selectable by the user.
nit: s/exactly like it is on Intel//
ok.
This way there are no surprises when running any tools on either vendor and ifThis patch, once minimized for easier backporting and marked for stable, would
one wants something special, one selects it.
accomplish this.
Two nitpicks:
* "no surprises" should be "no surprises (as long as AMD hardware does not return
"Unavailable")".
There is the known issue with the default mode on AMD where return of "Unavailable"
is treated as wraparound by pqos.
* "one wants something special" should be "one wants accurate data".
Caveat: User does not know how inaccurate data is in default mode. Users need to learn
about existence of accurate data from outside resctrl via external sources, possibly
leaving it up to the tools considered here.
I can capture these limitations in the documentation(resctrl.rst).
Is that what you're suggesting?
What is the plan with https://github.com/intel/intel-cmt-cat/issues/311 ?
I see a few possible options:
1. Use a workaround by mounting resctrl, setting mbm_assign_mode to default, and rerunning pqos. We can also document this limitation(Unavailable).
2. Reference the commit ID once the patch is merged.
3. Reach out to the pqos maintainers to explore any other available options.
sidenote:
Separate from this I again would like to propose that AMD work with pqos folks on
how pqos should handle the various text return values to fix the wraparound
issue. For example, is the preference for counting to stall at a number until the
hardware reports data again (so that user space always just sees numbers and not
be surprised by text) or should the text value (for example "Unavailable") be passed
on to user space or ...? The current wraparound issue should be fixed but it is
difficult for me to gauge what solution users would find least surprising. My
expectations from users do seem to be on the high side.
Yes, this has been a longstanding issue on AMD platforms. So far, we haven't found a viable solution. Hopefully, AMD will eventually provide support for all the counters that are advertised as supported.
Thanks
Babu