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

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

Hi Reinette,

On 6/11/2026 12:13 AM, Reinette Chatre wrote:
> Hi Chenyu,
> 

[ ... ]

>>> 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
>>>
>>
>> This may be slightly off-topic from MAX emulation, but I have another
>> thought regarding multi-controllers for rdt_resource:
>> As we know, with N regions, an MB resource will have a total of N × 3
>> controllers. Given that the current PoC iterates through every controller
>> within the resource in resctrl_resource_ctrl_get(), could this increase
>> lookup latency?
> 
> resctrl_resource_ctrl_get() is only called when the user writes to the
> schemata file and since user can modify any of the enabled controls with
> a write to the schemata file it is necessary to iterate through all controls
> to find a match.
> 

Yes, I was thinking if we can speed up this write by not iterating the 
control
list.

>>
>> I studied the cgroup code and found that each controller for a cgroup
>> resource uses a dedicated cftype. For example:
>> static struct cftype memory_files[] = {
>>      { .name = "min",  .write = memory_min_write,  .seq_show = memory_min_show },
>>      { .name = "max",  .write = memory_max_write,  .seq_show = memory_max_show },
>>      ...
>> };
> 
> The PoC currently has "static struct rftype ctrl_files[] " that associates an
> rftype with every property of a control which enables all user space interactions
> with the individual controls to be direct.
> 

Yes we have dedicated rftype for the read-only info/properties.

>>
>> The min/max memory controllers can be accessed in O(1) time using:
>> of_cft(of) -> kn->priv, and cft->write(of, buf, ...)
>>
>> rftype is resctrl's equivalent of cftype, and schemata is currently implemented
>> as a single rftype. Would it make sense to define a separate rftype for each
>> resctrl controller(or maybe in the future consider that this is not in a critical path)
> 
> Your suggestion is not clear to me. The schemata file is associated with a control group,
> a resource group that has multiple allocations each backed by a different controller.
> 
> I do not think I fully understand your suggestion so would appreciate if you could
> provide more detail.
> 

Sorry, I did not describe this precisely. My original thought is that 
when writing
schemata, we need to locate the control by iterating through the control 
list:
rdtgroup_schemata_write
   for_each_resource_ctrl(ctrl, r)
     if (!strncmp())
       return ctrl;
   parse_line("0=80;1=60", ctrl)

I just wonder if we can skip iterating the control list, by
giving each control a dedicated rftype(and rftype needs to introduce
a pointer struct resctrl_ctrl *ctrl)
rdtgroup_ctrl_schemata_write()
   rft = of->kn->priv
   parse_line("0=80;1=60", rft->ctrl)

thanks,
Chenyu