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

["Moger, Babu" <bmoger@amd.com>]

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

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