Re: [PATCH v4 26/41] arm_mpam: resctrl: Add support for 'MB' resource

[Zeng Heng]

On 2026/2/19 0:22, Ben Horgan wrote:
> Hi Fenghua, Zeng,
>
> On 2/16/26 13:54, Ben Horgan wrote:
> > Hi Zeng,
> >
> > On 2/13/26 07:38, Zeng Heng wrote:
> > > Hi Ben,
> > >
> > > On 2026/2/6 0:50, Jonathan Cameron wrote:
> > > > On Tue, 3 Feb 2026 21:43:27 +0000
> > > > Ben Horgan <ben.horgan@xxxxxxx> wrote:
> > > >
> > > > > From: James Morse <james.morse@xxxxxxx>
> > > > >
> > > > > resctrl supports 'MB', as a percentage throttling of traffic from the
> > > > > L3. This is the control that mba_sc uses, so ideally the class chosen
> > > > > should be as close as possible to the counters used for mbm_total. If
> > > > > there is a single L3 and the topology of the memory matches then the
> > > > > traffic at the memory controller will be equivalent to that at egress of
> > > > > the L3. If these conditions are met allow the memory class to back MB.
> > > > >
> > > > > MB's percentage control should be backed either with the fixed point
> > > > > fraction MBW_MAX or bandwidth portion bitmaps. The bandwidth portion
> > > > > bitmaps is not used as its tricky to pick which bits to use to avoid
> > > > > contention, and may be possible to expose this as something other than a
> > > > > percentage in the future.
> > > >
> > > > I'm very curious to know whether this heuristic is actually useful on
> > > > many
> > > > systems or whether many / most of them fail this 'shape' heuristic.
> > >
> > > The current MPAM driver has restrictions that limit MB control support.
> > > For example, on some systems, the MPAM memory class MSCs are not located
> > > at the L3 cache but rather at the memory controller (e.g., Mata). In
> > > such cases, MB control and mbm_total bandwidth monitoring cannot be
> > > enabled.
> > > > I'm unsure whether the community would welcome and be willing to review
> > > a patch series supporting such systems. Of course, the changes would
> > > involve minor refactoring in the resctrl common layer.
> >
> > Having MSC at the memory controllers is quite common and it would be
> > good for the mpam driver and resctrl to support this. My current
> > priority is the initial MPAM support and look at this and other extra
> > features later but I'd be happy to help progress support in this area
> > through review and discussion. There is some discussion about adding new
> > schema at [1] and we should make sure  this is consistent with monitors
> > too. James has some out of tree patches from before that disccussion at [2].
> >
> > [1] https://lore.kernel.org/lkml/aPtfMFfLV1l%2FRB0L@xxxxxxxxxxxxxxx/
> > [2] git://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git
> >   mpam/snapshot+extras/v6.18-rc1

Thank you for the information.

> Fenghua gave a talk at LPC on supporting cpu-less numa nodes in resctrl
> so is likely to have some patches/ideas around measuring bandwidth at
> memory controllers.

I also listened to the LPC presentation on this subject. The Kunpeng
memory controller is per-NUMA, however not CPU-less.

From an interface perspective, the interface that the Kunpeng memory
controller MSC solution aims to provide is somewhat similar to the
approach offered by Reinette:

"
One idea on how to accommodate this from resctrl side:
https://lore.kernel.org/lkml/fb1e2686-237b-4536-acd6-15159abafcba@xxxxxxxxx/

mon_data
├── mon_L3_00       <== monitoring data at scope L3
│   ├── llc_occupancy
│   ├── mbm_local_bytes
│   └── mbm_total_bytes
├── mon_L3_01       <== monitoring data at scope L3
│   ├── llc_occupancy
│   ├── mbm_local_bytes
│   └── mbm_total_bytes
├── mon_NODE_00     <== monitoring data at scope NODE
│   └── mbm_total_bytes
└── mon_NODE_01     <== monitoring data at scope NODE
    └── mbm_total_bytes
"


Best regards,
Zeng Heng