Re: [RFC PATCH v2 00/19] resctrl: Generalize monitor events across resources

[Jinjie Ruan]

在 2026/10/31 1:09, Reinette Chatre 写道:
> Hi Jinjie,
> 
> On 10/29/26 5:35 AM, Jinjie Ruan wrote:
>> Resctrl only knows about monitoring at the L3 scope. MPAM monitors are
>> attached to a resource in an MSC, and firmware says which cache level that
>> resource is. The driver already finds L2 monitors, but resctrl has
>> nowhere to show them.
>>
>> This is not MPAM specific. RISC-V can also place monitors at several
>> points in the system.
>>
> 
> One key to this is in the first sentence of this cover letter: "Resctrl only knows
> about monitoring at the L3 *scope*.".
> 
> When it comes to exposing monitoring data to user space resctrl has been using "L3"
> interchangeable as resource and scope. 
> 
> The existing resctrl user interface already establishes that the "L3" in
> "L3_MON" and the per monitor group "mon_data/mon_L3_xx" refers to the L3 *scope*,
> not the L3 resource. More specifically, consider the existing user interface:

Hi Reinette,

Thanks for your explanation, you are right, the "L3" in "L3_MON" and
"mon_L3_xx" is the scope, not the resource, this interface can include
different resources such as MB and L3 at the same time..

> 
> # find mon_data/
> mon_data/
> mon_data/mon_L3_00
> mon_data/mon_L3_00/mbm_local_bytes <=== monitoring data associated with MB resource at L3 scope
> mon_data/mon_L3_00/mbm_total_bytes <=== monitoring data associated with MB resource at L3 scope
> mon_data/mon_L3_00/llc_occupancy   <=== monitoring data associated with L3 resource at L3 scope
> 
> Associating the monitor events with the L3 resource was an implementation choice
> that was convenient at the time. Since L2 can similarly be used interchangeably for resource
> and scope associating the L2 scope monitoring with the L2 resource may similarly be convenient
> when considering how to support L2 monitors as is done in this series.

L2 works here only because the names happen to be the same for resource
and scope as L3 has done.

> 
> Even so, I do not believe that associating monitoring with the resource will be
> able to cleanly support all MPAM monitoring capability. Specifically the upcoming CPU-less
> memory bandwidth monitoring.
> 
> As I see the plan at this time: CPU-less memory bandwidth allocation will be
> backed by a new MB_NODE resource. For these systems the expectation is that their
> monitoring data will be exposed to user space via NODE scope and will appear to user space as:
> 
> mon_data/
> mon_data/mon_NODE_00
> mon_data/mon_NODE_00/mbm_total_bytes <=== monitoring data associated with MB resource at NODE scope

You are righ, associating monitoring with the resource cannot give
mon_NODE_00 but mon_MB_xx. I am happy to key it off scope instead for
naming and display, and keep the resource-based event tables as an
internal detail.

> 
> The cover-letter is titled "Generalize monitor events across resources". As I see it such
> generalization does not prepare resctrl for all MPAM monitoring capabilities. Could this
> work do so?

CPU-less NODE monitoring is not part of this series, but I will make
sure the scope-based naming does not block it.

> 
> Reinette

-- 
Best regards,
Jinjie