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

Chen, Yu C
2026-01-09T16:09:41Z

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