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

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

Hi Boris,

On 8/4/26 3:47 PM, Borislav Petkov wrote:
> 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?

Expanding on what Tony answered ...

The 64 magic number only applies to AMD.

In default mode both Intel and AMD enumerates the number of RMIDs supported
by each resource and both Intel and AMD limits the number of monitor groups
a user can create to the minimum RMID ("minRMID" below) supported across all
resources.

On Intel the monitoring behavior is consistent no matter how many monitor groups the
user creates. User can create up to minRMID monitor groups and reading monitoring
data from all the monitor groups always return accurate data (never "Unavailable").

On AMD the monitoring behavior (without assignable counters, aka "default mode") changes
depending on how many monitor groups the user creates:
User creates 0 to 64 monitor groups:
	reading monitoring data from any of these monitor groups will always return data
	and it will be accurate

User creates from 65 to minRMID monitor groups:
	reading monitoring data from *any* monitor group may return "Unavailable" and
	vary in accuracy


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

If this cannot be reproduced on AMD hardware then AMD did not need to create ABMC, no?

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

Agreed and matches above summary. The arch limit here would be the 64 RMID that can
be guaranteed to be counted. resctrl does not limit the number of monitor groups to
this number though but instead uses the number enumerated from hardware (4096 on this hardware).
To guarantee accurate data in "default" mode a solution could be to add model specific
information that teaches resctrl about "64" and it can use that as RMID limit instead.

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

I expect so also. Even so, it does open a new question of if and how tools are
expected to interact with assignable counters. Instead of this bug I would propose
that AMD work with pqos folks on expectations from tools to support assignable
counters. To me this bug implies that AMD considers enabling assignable mode on
a system as a bug. 

Reinette