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

> > Intel systems have counters backing up every RMID. So CPUD leaf 0xF tells
> > Linux how many can be used.
>
> Are you saying that there is not an Intel system out there which has less
> counters than RMIDs? If so, that would explain why the exhaustion happens on
> AMD only.

When talking about the L3 events (L3 cache occupancy, memory bandwidth) this
is accurate. All RMIDs have counters for each event on every product.

AET (Application Energy Telemetry) has separate enumeration for number of
RMIDs supported (via VSEC entries in the PCIe device that maintains the counters).
Although that device is on package, the mix and match between stuff on the package
and the CPU cores, may mean number of AET RMIDs is not equal to number of
L3 RMIDs. If AET has more, they are wasted and can't be used. If AET has less, then
resctrl drags the limit down to make sure everything that the user sees in the resctrl
file system will work.

Region aware extensions have same issue (only difference is that the enumeration
is via ACPI instead of PCIe).

>
> /me goes and looks at the SDM:
>
> So there's leaf 0 there:
>
> EBX[31:0]     MAX_RMID        Maximum range (zero-based) of RMID within this
> physical processor of all types.
>
> I'm assuming that means you have so many RMIDs and all of them are backed by
> counters.

Yes.

>
> And if we look at one example if Emerald Rapids:
>
> CPUID 0000000F: 00000000-0000007F-00000000-00000002 [SL 00]
> CPUID 0000000F: 00000008-00008000-0000007F-00000007 [SL 01]
>
> https://instlatx64.github.io/InstLatx64/GenuineIntel/GenuineIntel00C06F2_EmeraldRapids_02_CPUID.txt
>
> That 0x7f there means 128 counters for 128 RMIDs so there cannot be any
> exhaustion.

Technically two values of interest. CPUID(0xF,0).EBX gives the max value of RMID for any
monitoring feature. CPUID(0xF,n).ECX gives the max value for the feature in subleaf "n"
(though we've only ever implemented subleaf 1 for the L3 occupancy and memory bandwidth
features ... so the two values have been the same so far)
>
> Am I close?

You are all the way there :-)

-Tony