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

[Reinette Chatre <reinette.chatre@intel.com>]

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 if
> one wants something special, one selects it.
This patch, once minimized for easier backporting and marked for stable, would
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.

What is the plan with https://github.com/intel/intel-cmt-cat/issues/311 ?

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.

Reinette