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

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

Hi Chenyu,

On 6/10/26 12:09 AM, Chen, Yu C wrote:
> 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.

-  This implies that all current and future ERDT capable systems will keep
   supporting MSR access with the legacy "percentage based control". Is this
   accurate? What will behavior be on an ERDT system that does not support
   MSR access with the percentage-based control?
-  It is not obvious to me what you plan to have as default interface -
   I believe this should be "legacy" interface to ensure this will not
   break user space. resctrl should only switch to "native" after user
   demonstrates (by switching) familiarity with the new interface.

Reinette