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

[Fenghua Yu]

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

> > > > > +
> > > > > +  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/?

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

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