Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept

[Reinette Chatre]

Hi Shaopeng,

On 6/11/26 6:30 PM, Shaopeng Tan (Fujitsu) wrote:
> Hello Reinette, Ben, Drew,
> 
>> On Thu, Jun 04, 2026 at 02:47:39PM -0700, Reinette Chatre wrote:
>>>> The ability to change scope is much needed for RISC-V. There are
>>>> compromises in my RFC [1] as a result of trying to map everything to
>>>> either L2 or L3 scope.
>>>>
>>>> I would also like to see a non-cpu cache scope for monitoring too, but
>>>> would that be better discussed outside the context of this proof of
>>>> concept?
>>>
>>> I also think it would be good for it to be clear that monitoring is based on
>>> scope, not a resource. With the MB controls supporting different scope I do think
>>> that this would be a good next step. A previous musing from me on this topic can
>>> be found (at the end of ) https://lore.kernel.org/lkml/fb1e2686-237b-4536-acd6-15159abafcba@xxxxxxxxx/
>>>
>>> I have not yet considered how this can be built on top of this PoC though.
>>
>> Thanks for explaining. I like how how you show an example of
>> mon_data/mon_NODE_00/mbm_total_bytes in that thread. I believe that sort
>> of scheme would work well for RISc-V as a bandwidth controller
>> implementing the CBQRI spec can be located anywhere within the system.
> 
> I have a few questions regarding the scope parameter and the name "mbm_total_bytes".
> 
> First, concerning the scope parameter, does the "NODE" specified in "scope" refer to a NUMA node?

Yes.

> If so, wouldn't using "NUMA" directly be more explicit and user-friendly? 
> Could you please explain why "NODE" is used instead of "NUMA"?

By using "node" the idea is to create an interface that is familiar to user space. Since 
/sys/devices/system/node already exists to expose the NUMA layout to user space I expect that
using similar terminology would make the resctrl interface easier to use since it would be clear
that a "node" in /sys/devices/system/node would have a matching "node" in resctrl.

> 
> Second, regarding the naming of "mbm_total_bytes",
> the meaning of this name seems to differ from what is typically found under mon_data/mon_L3_<id>/mbm_total_bytes. 

Could you please elaborate how the meaning is different? The only information I have about
the systems needing this is in Nvidia's portion of
https://lpc.events/event/19/contributions/2093/attachments/1958/4172/resctrl%20Microconference%20LPC%202025%20Tokyo.pdf

> To avoid confusion and better reflect its different nature, 
> how about considering an alternative name such as mbm_global_bytes or another more appropriate identifier.

Reinette