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

[Fenghua Yu]

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

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