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

[Ben Horgan]

Hi Fenghua,

On 7/2/26 16:16, Fenghua Yu wrote:
> Hi, Ben,
> 
> On 7/2/26 06:37, Ben Horgan wrote:
>> Hi Fenghua,
>>
>> On 6/25/26 02:26, Fenghua Yu wrote:
>>> Hi, Reinette,
>>>
>>> On 6/24/26 15:22, Reinette Chatre wrote:
>>>> Hi Fenghua,
>>>>
>>>> On 6/24/26 12:08 PM, Fenghua Yu wrote:
>>>>> Hi, Reinette, Ben, Shaopen, et al,
>>>>>
>>>>> On 5/29/26 11:06, Reinette Chatre wrote:
>>>>>
>>>>> As Shaopen and Ben mentioned earlier, we are working on two MPAM
>>>>> features that may need to change schemata interface. The CPU-less
>>>>> feature was discussed on LPC (although the interfaces will be
>>>>> slightly different from the LPC).
>>>>
>>>> I know. Here is where I tried to engage with you on needed interfaces
>>>> after LPC:
>>>> https://lore.kernel.org/lkml/fb1e2686-237b-4536-
>>>> acd6-15159abafcba@xxxxxxxxx/
>>>
>>> MPAM ACPI defines MSC (Memory System Control) is defined in one of two
>>> ways (not both) on one platform:
>>> 1. L3 and memory together on each processor MSC
>>> 2. L3 in processor MSC and memory control/monitoring in different memory
>>> MSCs.
>>
>> On one platform, if there are MSC with memory bandwidth monitors or
>> controls in both your slc and at the memory controllers then the MPAM
>> ACPI tables would describe those at the memory as being at the memory
>> and those at the cache.
>>
>> This could lead to having memory bandwidth controls/monitors at both L3
>> and memory scope.
>>
> 
> The locator type in MSC for this L3 is still 1, right?
> 
> So the control and monitor example could be:
> 
> MSC0: type 1 L3 with cache id 0 on socket 0
> MSC1: type 1 L3 with cache id 1 on socket 1
> MSC2: type 2 memory with numa node 1 on socket 0
> MSC3: type 2 memory with numa node 1 on socket 1
> 
> The schemata file could be:
>      L3: 0=fff;1=fff <-- cache control on cache id
>      MB: 0=fff;1=fff <-- memory bandwidth control on cache id. legacy.
> MB_NODE: 1=100;2=100 <-- memory bandwidth conttrol on node id. CPU-less
> 
> Cache and memory bandwidth monitoring:
> On cache id 0, both llc_occupancy and total_bytes are monitored:
> mon_data/mon_L3_00/mbm_llc_occupancy
> mon_data/mon_L3_00/mbm_total_byptes
> On cache id 1, both llc_occupancy and total_bytes are monitored::
> mon_data/mon_L3_01/mbm_llc_occupancy
> mon_data/mon_L3_01/mbm_total_bytes
> 
> On NUMA node 1, only total_bytes is monitored:
> mon_data/mon_NODE_01/mbm_total_bytes
> On NUMA node 2, only total bytes is monitored:
> mon_data/mon_NODE_02/mbm_total_bytes

Yes, this all looks sensible.

> 
>>> On type 1 platform, schemata is legacy:
>>> MB:1=100;2=100  <-- cache id 1 and 2 as domain id
>>>
>>> On type 2 platform, I will not reuse "MB:" name. Instead, define new
>>> resource name "MBN:" for numa node and schemata is:
>>> MBN:0=100;1=100;2=100;10=100;18=100;26=100 <-- numa id 0, 1, 2, 10, 18,
>>>                             26 as domain id
>>> On type 2 platform, there won't be "MB:" line. Numa 0 and 1
>>> are for mbm allocation on socket 0 and 1. 2,10, 18 and 26 are for GPU
>>> memory nodes allocation.
>>>
>>> BTW, Slow MBA (SMBA) is different from MBA Numa (MBN). SMBA still relies
>>> on L3 and the domain id in SMBA is still cache id. MBN depends on each
>>> memory controlor with numa id as domain id for both CPU and CPU-less
>>> memory nodes.
>>>
>>> On type 1 platform, there is only MB:
>>>
>>> info
>>> └── MB
>>>      └── resource_schemata
>>>          ├── MB
>>>          │   ├── max
>>>          │   ├── min
>>>          │   ├── resolution
>>>          │   ├── scale
>>>          │   ├── scope <== contains "L3"
>>>          │   ├── tolerance
>>>          │   ├── type
>>>          │   └── unit
>>>
>>> On type 2 platform, there is only MBN:
>>> info
>>> └── MBN
>>>      └── resource_schemata
>>>          ├── MBN
>>>          │   ├── max
>>>          │   ├── min
>>>          │   ├── resolution
>>>          │   ├── scale
>>>          │   ├── scope <== contains "NUMA"
>>>          │   ├── tolerance
>>>          │   ├── type
>>>          │   └── unit
>>>
>>> This is different from the "scope" hierarchy discussed in the link. "MB"
>>> and "MBN" won't exist on the same platform.
>>>
>>> I find it's hard (and not useful) to split "MB" for memory with CPU and
>>> "MBN" for CPU-less memory node. It's easier to have either "MB" for
>>> legacy memory with CPU or "MBN" for CPU-less memory.
>>
>> yes, I don't think CPU-less memory needs special casing in the interface
>> once there is support for NUMA scope.
>>
>>>
>>> Any thoughts? Does this update make sense?
>>
>> I think a _NODE postfix for controls with NUMA scope makes sense. I
>> brought up naming of controls when they are the same but have different
>> scope earlier in the thread and Reinette pointed me at this earlier
>> discussion.
> 
> Is _NODE postfix sufficient for future?
> 
> e.g. SMMU locator id is IORT table node id. AFAICT, the node id is not a
> numa node. If that's the case, _NODE postfix may cause confusion here.
> 
> Is explict "_NUMA" postfix clearer?

How is the SMMU locator id displayed to the user?

For the NUMA node id we already use the name node in sysfs,
/sys/devices/system/node/node<node_id>

Thanks,

Ben

> 
> [SNIP]
> 
> Thanks.
> 
> -Fenghua