[PATCH v4 5/5] arm64: mpam: Add memory bandwidth usage (MBWU) documentation

[Ben Horgan]

Hi Fenghua,

On 7/2/26 16:46, Fenghua Yu wrote:
> Hi, Ben,
> 
> On 7/2/26 07:58, Ben Horgan wrote:
>> 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.)
> 
> s/It/The platform/?

ok

> 
>>>>>> +
>>>>>> +  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
> 
> s/a single global L3/a single global L3 cache id/?

"a single global L3" seems better to me. This is just saying that the L3
is or appears to be a single L3 cache. A consequence of which is that it
will have a single cache id.

> 
>>>>>> +  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
> 
> Maybe remove the CPU-less example here since you will add CPU-less info
> later?
> 
> The CPU-less patches will update this document accordingly.

I think this can stay until then. It is mentioned after this that the
restrictions are not fundamental.

Thanks,

Ben

> 
>>>>>> +  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
>>
> Thanks.
> 
> -Fenghua