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

[Fenghua Yu <fenghuay@nvidia.com>]

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@intel.com/
>>
>> 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

>> 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?

[SNIP]

Thanks.

-Fenghua