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

["Chen, Yu C" <yu.c.chen@intel.com>]

Hi Reinette,

On 6/10/2026 1:41 AM, Reinette Chatre wrote:
> Hi Ben,
> 
> On 6/9/26 9:37 AM, Ben Horgan wrote:
>> On 6/9/26 16:28, Reinette Chatre wrote:
>>> On 6/9/26 3:10 AM, Ben Horgan wrote:
>>>> On 6/8/26 17:16, Reinette Chatre wrote:
> 
> 
>>>> I don't see the advantage of emulating MB with both MIN and MAX. Just going by
>>>> the MPAM specification, a system keeping MIN at 0 and just setting MAX from MB,
>>>> (MIN=0, MAX=MB) should behave the same as one always setting both, (MIN=MB,
>>>> MAX=MB). In the MIN=0 case there is never any high preference traffic and in the
>>>> MIN=MAX_MB case there is never any medium preference traffic. It seemed best to
>>>> not rely on any platform specific heuristics to try and guess what's better and
>>>> just wait til the time we could support MB_MIN in resctrl (and leave the
>>>> decision up to the user). My expectation was that this would be the simplest
>>>> course of action.
>>>
>>> This sounds fair. Two observations:
>>> - The hierarchy exposed by resctrl may be different on systems that have the "same"
>>>    controls.
>>>    For example, on an MPAM system (if I understand correctly) the user may see:
>>>    info/
>>>    └── MB/
>>>        └── resource_schemata/
>>>            ├── MB/
>>>            │   └── MB_MAX/
>>>            └── MB_MIN/
>>
>> Yes, this matches my understanding.
>>
>>>
>>>    Compared with a possible implementation on Intel that looks like:
>>>    info/
>>>    └── MB/
>>>        └── resource_schemata/
>>>            ├── MB/
>>>            │   └── MB_OPT/
>>>            ├── MB_MAX/
>>>            └── MB_MIN/
>>
>> Not sure if my understanding is correct here...
>> In the kernel today is it rdt max that backs MB? (Ignoring the sw controller)
> 
> resctrl does not have support for the RDT "MAX" controller yet. Since resctrl was
> created as part of enabling RDT the resctrl MB control maps exactly to RDT's
> original percentage based memory delay value that is an approximate. Newer hardware
> support three controls: optimal, minimum, and maximum. These controls have finer
> granularity than what the default percentage based control supports so emulation
> is needed.
> So far I assumed that on these systems the default MB control would be emulated
> by the new "optimal" control but after these exchanges I can see there being an
> argument for it to be emulated by the new "maximum" control also. Apart from it
> implying a cap there is also the idea that the "maximum" control is more likely to
> be available on all platforms.
> 

Regarding the region-aware RDT case, I wonder if we actually need to 
emulate the
legacy MB control using MB_MAX. First, when we refer to the "legacy" for 
region-aware
RDT, I suppose it corresponds to "MSR access" plus "percentage-based 
control".

case 1:
If the platform does not support region-aware RDT (no ERDT table is 
detected),
the MB is naturally the "legacy" MB, and the info directory would look like:

info
└── MB
         └── resource_schemata
                 └── MB

case 2:If the platform supports region-aware RDT (i.e., ERDT parsing 
succeeds),
then the structure looks like below:

info
└── MB
         └── resource_schema
                 └── MB                  <=== legacy
                 └── MB_REGION0_OPT
                 └── MB_REGION1_OPT
                 └── MB_REGION0_MIN
                 └── MB_REGION1_MIX
                 └── MB_REGION0_MAX
                 └── MB_REGION1_MAX

The OS supports runtime switching between the legacy MB and
region-aware MB, via a MB scope control like:
/sys/fs/resctrl/info/MB/resource_schemata/mode
[legacy] native
If the user wants to use the legacy interface, the system
will fall back to the default [MSR-based, percentage]; if the
user wants to use the new interface, the region-aware interfaces
will be used. Since the two modes are mutually exclusive, there
seems to be no need to use MB_REGION0_MAX to emulate legacy MB.

thanks,
Chenyu