[PATCH v4 5/5] arm64: mpam: Add memory bandwidth usage (MBWU) documentation
Ben Horgan
ben.horgan at arm.com
Thu Jul 2 07:58:55 PDT 2026
Hi Reinette,
On 7/2/26 15:46, Reinette Chatre wrote:
> Hi Ben,
>
> On 7/2/26 2:20 AM, Ben Horgan wrote:
>> On 7/1/26 23:38, Reinette Chatre wrote:
>>> On 5/20/26 2:24 PM, Ben Horgan wrote:
>
> ...
>
>>>> --- a/Documentation/arch/arm64/mpam.rst
>>>> +++ b/Documentation/arch/arm64/mpam.rst
>>>> @@ -65,6 +65,23 @@ The supported features are:
>>>> there is at least one CSU monitor on each MSC that makes up the L3 group.
>>>> Exposing CSU counters from other caches or devices is not supported.
>>>>
>>>> +* Memory Bandwidth Usage (MBWU) on or after the L3 cache. resctrl uses the
>>>> + L3 cache-id to identify where the memory bandwidth is measured. For this
>>>> + reason the platform must have an L3 cache with cache-id's supplied by
>>>> + firmware. (It doesn't need to support MPAM.)
>>>> +
>>>> + Memory bandwidth monitoring makes use of MBWU monitors in each MSC that
>>>> + makes up the L3 group. If the memory bandwidth monitoring is on the memory
>>>> + rather than the L3 then there must be a single global L3 as otherwise it
>>>> + is unknown which L3 the traffic came from.
>>>> +
>>>> + To expose 'mbm_total_bytes', the topology of the group of MSC chosen must
>>>> + match the topology of the L3 cache so that the cache-id's can be
>>>> + repainted. For example: Platforms with Memory bandwidth monitors on
>>>> + CPU-less NUMA nodes cannot expose 'mbm_total_bytes' as these nodes do not
>>>> + have a corresponding L3 cache. 'mbm_local_bytes' is not exposed as MPAM
>>>> + cannot distinguish local traffic from global traffic.
>>>
>>> Hopefully we can get to a point where memory bandwidth monitoring data from
>>> CPU-less NUMA nodes can be exposed via resctrl. When considering such possible
>>
>> Thank you for your interest here. I hope so too.
>>
>>> future I think it may make this work easier to build on if the documentation
>>> focuses on what the current implementation supports and leave room for
>>> future enhancements by not constraining user space expectation with an absolute
>>> like "CPU-less NUMA nodes cannot expose 'mbm_total_bytes'".
>>
>> The intention was to describe the current limitations but I do see how
>> this can come across as fundamental problems rather than just that we
>> need to do some more work to establish how this can be done and
>> implement it.
>>
>> How about if I add this paragraph at the end?
>>
>> All these restrictions based on L3 cache are due to resctrl, currently,
>> only supporting monitoring at the scope of the L3 scope. It is expected
>
> How about "at L3 scope" instead of "at the scope of the L3 scope"?
Sure, that reads better.
Ben
>
>> that going forward more MBWU monitors can be exposed to the user after
>> support for more monitoring scopes is added to resctrl.
> Looks good to me, thank you.
>
> Reinette
More information about the linux-arm-kernel
mailing list