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

[Chen, Yu C]

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