Re: [RFC] fs/resctrl: Generic schema description

[Chen, Yu C]

Hi Dave,

On 1/7/2026 11:53 PM, Dave Martin wrote:
> Hi,
>
> On Fri, Dec 26, 2025 at 06:38:52PM +0800, Chen, Yu C wrote:

[snip]

> > >           │   ├── tolerance
> > >           │   ├── type
> > >           │   └── unit
> > >           └── SMBA_NODE
> > >               ├── max
> > >               ├── min
> > >               ├── resolution
> > >               ├── scale
> > >               ├── scope <== contains "NODE"
> >
> > Would it be more user-friendly to explicitly show "node0, node1, ..."
> > rather than "NODE"? After all, we can already infer the "NODE" type from
> > the schemata name "SMBA_NODE".
>
> I think that having an explicit declaration of the scope is probably
> useful even for things that are included in the schema name.
>
> Part of the reason for describing the schema explicitly is because
> inferring everything from the name does not feel scalable as we add
> more different schemata and resource types.

OK, this makes sense.

> Having said that, the schema names should still provide a good clue as
> to what the schema represents.
>
>
> I'm not sure that we should simply list possible domain IDs here:
>
> For MPAM, the domain IDs can be huge, random-looking numbers that do
> not necessarily start from 0 (as currently implemented in the MPAM
> driver).
>
> In any case, we need not just names for the individual domain IDs, but
> an idea of what they represent.
>
>
> Maybe we could stick with opaque "scope" names as in Reinette's
> proposal, and solve the problem of enumating the domain IDs separately.
>
>
> For the commonly-used scopes, we probably don't need to bother, since
> the enumeration is available elsewhere:
>
>   * for NUMA nodes and cache IDs, /sys/devices/system/node/node*
>     (or /sys/devices/system/node/possible) ?
>
>   * for cache IDs at level <n>, the set of values present in all the
>     files /sys/devices/system/cpu/cpu*/cache/index<n>/id ?

Previously, the node list display was proposed mainly to build a
connection between regions and nodes. If we know the node ID, we can
check the detailed information of that node via sysfs (such as
/sys/devices/system/node/node*).
But I agree that keeping the "scope" simple and displaying the
connection somewhere else is reasonable.

> > > │   └── mbm_total_bytes
> > > └── mon_NODE_01     <== monitoring data at scope NODE
> > >       └── mbm_total_bytes
> >
> > Please let me take this chance to elaborate on region-aware RDT
> > in more detail. I am wondering if the interface could be further
> > extended to support this feature.

[snip]

> > Users could query the exact definition of REGION1
> > by checking the info directory.
> >
> > info
> > └── MB
> >        └── resource_schemata
> >            ├── MB_REGION1_OPT
> >            │   ├── max
> >            │   ├── min
> >            │   ├── resolution
> >            │   ├── scale
> >            │   ├── scope <== "0=node2;1=node3" (node2 on S0, node3 on S1)
> >            │   ├── tolerance
> >            │   ├── type
> >            │   └── unit
>
> Hmmm, that's interesting.
>
> If there is a grouping on NUMA nodes, is that advertised anywhere in
> sysfs already?
>
> Ideally, there would already be a definition of what "region 0" is in
> terms of the NUMA topology, and we could just refer to it.

We have a sysfs interface exposed in /sys/firmware/acpi/memory_ranges/;
each entry represents a physical address range with local or remote region
IDs. I think we can build based on this interface.

thanks,
Chenyu