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

[Borislav Petkov <bp@alien8.de>]

On Tue, Aug 04, 2026 at 03:10:18PM -0700, Reinette Chatre wrote:
> > 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//

What does that mean?

What's the difference between Intel's RMID mode + 64 counters and AMD's?

> 
> 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")".

AFAIK, Babu was unable to reproduce that.

>    There is the known issue with the default mode on AMD where return of "Unavailable"
>    is treated as wraparound by pqos.

I guess Babu can address that.

> * "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.

With my simple thinking, I would expect that accurate data means, the number
of counters being in use is not hitting the arch limit. The moment that
happens, I guess one could deem that measurement innacurate.

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

I guess that should be closed once we switch back the default.

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

Agreed.

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

I'd go for "the least surprises possible" approach here. But I'd let Babu
comment here about the specifics.

Thx!

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette