Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept

[Reinette Chatre]

Hi Chenyu,

On 7/17/26 9:02 AM, Chen, Yu C wrote:
> Hi Reinette,
> 
> On 7/17/2026 12:04 AM, Reinette Chatre wrote:
>> Hi Ben, Chenyu, and Tony,
>>
> 
> [ ... ]
> 
>>>>> Alternatively, could the "mode" file be used to switch between "MB" and "MB_MAX" and the two never
>>>>> need be shown at the same time. The user opts in to using the new interface, "MB_MAX" by setting
>>>>> "mode" and can just toggle back if they want to use "MB" directly again.
> 
> Would this approach also work for region‑aware MBA, where a "mode" file is used to
> toggle between "MB" and "MB_REGIONx_MAX", ensuring that the two are never displayed
> simultaneously in the schemata?

The goal is indeed for this approach to work for all features we are currently
aware of. Please do point out if it does not.

> 
> [ ... ]
> 
>> RDT region aware when using MSR interface for legacy controls
>> =============================================================
> 
> Do you mean there is a requirement to use the MSR interface when region‑aware
> MMIO is available? My thought was that, if fine‑grained control(like MMIO) is
> available, it would be good to always let the fine‑grained control emulate the
> legacy one.

resctrl makes no requirement to use MSR interface when region-aware MMIO is available.
 
> And I'm trying to figure out the definition of "legacy controls":
> Previously I thought that "legacy control" means using the existing MB interface
> in the schemata to change the percentage value. That is to say, no matter whether
> the underlying mechanism is based on MSR or MMIO, it is transparent to the
> resctrl user.

That is correct.

> 
> For example, if the mode is "legacy", and user writes "MB:0=50" to the schemata
> file,
> 1. If that platform only supports the MSR interface, then it will be translated
> into an MSR write. Or,
> 2. If that platform supports MMIO access (i.e., the ACPI table is available),
> we convert 50 into 50 × 255 / 100, and write it to the MMIO address. In this way,
> the user still sees the "legacy" interface.

The requirement here is that when user space writes, as in your example,
"MB:0=50" then user space expects 50% bandwidth allocation. The underlying hardware
MMIO control could be used if there exists a conversion from percentage memory bandwidth
to the underlying hardware control value. I do not believe such conversion exists for
all hardware that support the MMIO interface. Specifically, from what I understand,
50 × 255 / 100 in MMIO cannot be guaranteed to represent 50% memory bandwidth? On
systems where such conversion can be made it is indeed possible to use MMIO for
the legacy "MB" control.

>> 1) System default
>>
>> info hierarchy
>> --------------
>> info/
>> └── MB/
>>      └── schemata/
>>          ├── MB/
>>          │   ├── MB_REGION0_MAX/
>>          │   │   └── status:disabled
>>          │   ├── MB_REGION1_MAX/
>>          │   │   └── status:disabled
>>          │   ├── MB_REGION2_MAX/
>>          │   │   └── status:disabled
>>          │   ├── MB_REGION3_MAX/
>>          │   │   └── status:disabled
>>          │   └── status:enabled
>>          └── mode:[legacy] native
>>
>> schemata file
>> -------------
>> MB:...
>>
>> 2) User space switches to fine grained controls
>>
>> # echo "native" > /sys/fs/resctrl/info/MB/schemata/mode
>>
>> info hierarchy
>> --------------
>> info/
>> └── MB/
>>      └── schemata/
>>          ├── MB/
>>          │   ├── MB_REGION0_MAX/
>>          │   │   └── status:enabled
>>          │   ├── MB_REGION1_MAX/
>>          │   │   └── status:enabled
>>          │   ├── MB_REGION2_MAX/
>>          │   │   └── status:enabled
>>          │   ├── MB_REGION3_MAX/
>>          │   │   └── status:enabled
>>          │   └── status:disabled
>>          └── mode:legacy [native]
>>
>> schemata file
>> -------------
>> MB_REGION0_MAX:...
>> MB_REGION1_MAX:...
>> MB_REGION2_MAX:...
>> MB_REGION3_MAX:...
>>
>>
> 
> If I understand correctly, the "enable/disable" knobs are used to decide
> whether to display this  control in the schemata file. If we make legacy
> and native exclusive, do we still need the "enable/disable" knob?

Indeed. If the controls are exclusive then the "enable/disable" knobs 
are not required to force them to be exclusive (but also see below).

There may still be scenarios where controls need to be enabled explicitly and
thus a need to keep the enable/disable knob. Here I am thinking about, for
example, in MPAM that controls could be enabled/disabled (like MPAMCFG_MBW_PROP.EN for
proportional-stride partitioning).

> 
> On a platform where MSR/MMIO are both available:
> 
> 1) System default
> 
>  info hierarchy
>  --------------
>  info/
>  └── MB/
>       └── schemata/
>           ├── MB/
>           │   ├── MB_REGION0_MAX/
>           │   ├── MB_REGION1_MAX/
>           │   ├── MB_REGION2_MAX/
>           │   ├── MB_REGION3_MAX/
>           └── mode:[legacy] native
> 
>  schemata file
>  -------------
>  MB:...
> 
>  2) User space switches to fine grained controls
> 
>  # echo "native" > /sys/fs/resctrl/info/MB/schemata/mode
> 
>  info hierarchy
>  --------------
>  info/
>  └── MB/
>       └── schemata/
>           ├── MB/
>           │   ├── MB_REGION0_MAX/
>           │   ├── MB_REGION1_MAX/
>           │   ├── MB_REGION2_MAX/
>           │   ├── MB_REGION3_MAX/
>           └── mode:legacy [native]
> 
>  schemata file
>  -------------
>  MB_REGION0_MAX:...
>  MB_REGION1_MAX:...
>  MB_REGION2_MAX:...
>  MB_REGION3_MAX:...
> 
> 

Above looks to be where resctrl is headed at the moment. It may still
be helpful to keep the "enable/disable" knobs to describe to user space
when emulation is active. Specifically, when mode is "legacy" then there
could be two region-aware scenarios: use MSR directly or use MMIO to emulate.
Having the "enable/disable" knob will help to distinguish these two scenarios.

Reinette