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

Hi Babu,

On 8/4/26 4:44 PM, Moger, Babu wrote:
> 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?

Are you referring to the nitpicks? I am not suggesting that you take any action based on it.
I quoted text in a message that I do not 100% agree with and highlighted why. My goal for
doing this was just to confirm we are all on the same page.

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

The end goal is not clear to me here. Without having a goal it is difficult to
explore steps to get there.

One goal mentioned in changelog is to ensure pqos users have a great experience
when using pqos on AMD hardware. Do you expect that pqos users may want to use
assignable counters to get accurate data? If so, is there a plan for these pqos
users to be able to use assignable counters via pqos? 

I do not see mention of a goal or expectation in that issue and as it is written
I interpret it as "enabling assignable counters on AMD is a bug". This interpretation
is supported by the options you list above.
To me this contradicts a goal of supporting pqos users on AMD hardware.

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

I'm confused. Are you saying that you have not found a viable solution for
the pqos wraparound issue? But .... you did not even report it to the pqos
team! Are you really suggesting that the fix requires a new AMD hardware feature?
In the mean time software can address it, no? 
Reinette