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

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

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