linux-kernel - Re: [RFC] fs/resctrl: Generic schema description

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <8255113f-082a-421b-a8ac-dc93a7b64e10@intel.com>
Date: Sat, 10 Jan 2026 00:09:19 +0800
From: "Chen, Yu C" <yu.c.chen@...el.com>
To: Dave Martin <Dave.Martin@....com>
CC: Reinette Chatre <reinette.chatre@...el.com>, Babu Moger
	<babu.moger@....com>, Fenghua Yu <fenghuay@...dia.com>, Tony Luck
	<tony.luck@...el.com>, James Morse <james.morse@....com>, Thomas Gleixner
	<tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov
	<bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin"
	<hpa@...or.com>, Jonathan Corbet <corbet@....net>, <x86@...nel.org>,
	<linux-kernel@...r.kernel.org>, <fustini@...nel.org>
Subject: Re: [RFC] fs/resctrl: Generic schema description

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