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

[Zeng Heng <zengheng4@huawei.com>]

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@arm.com> wrote:
>>>>
>>>>> From: James Morse <james.morse@arm.com>
>>>>>
>>>>> 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@e133380.arm.com/
>> [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@intel.com/

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