Re: [PATCH v1 2/4] fs/resctrl: Only show 'event_filter' files if events are configurable

[Reinette Chatre]

Hi Ben,

On 3/3/26 6:00 AM, Ben Horgan wrote:
> Hi Reinette,
> 
> On Mon, Mar 02, 2026 at 03:12:52PM -0800, Reinette Chatre wrote:
>> Hi Ben,
>>
>> On 2/25/26 12:19 PM, Ben Horgan wrote:
>>> When the counter assignment mode is mbm_event resctrl assumes the mbm
>>> events are configurable and exposes the 'event_filter' files. These files
>>> live at info/L3_MON/event_configs/<event>/event_filter and are used to
>>> display and set the event configuration.
>>>
>>> ABMC always supports event configuration but for MPAM they are
>>> independent. Decouple event configuration from counter assignment by only
>>
>> Could you please elaborate what you mean with "independent" here? If event
>> configuration is still supported when assignable counter mode is enabled, why
>> can event configuration interface not just remain as-is? Could resctrl not
> 
> The two features of ABMC that I'm claiming are independent are: firstly,
> requiring assignment of a hardware counter to to CTRL_MON/MON group in order to
> allow using bandwidth monitoring when there are fewer hardware counters than
> possible CTRL_MON/MON groups (num_rmid) and secondly bandwidth type
> configuration for the counters.

These are implemented separately in resctrl fs.


> The first is concerned with which, if any, hardware counter is used per group
> and the second with what the counters are counting. To me these as appear as two
> things that should be considered separatedly. Is this clearer?

They can, and indeed resctrl manages these two parts of assignable counters with
two separate interfaces.

> 
> I'm first trying to address the case where event configuration isn't supported
> as we haven't currently got support for that in the MPAM driver and supporting
> systems with fewer hardware counters than (PARTID, PMG) without unnecessary
> limiting the exposed PARTID/PMG. Some MPAM hardware systems only have a single
> bandwidth counter.

ok, but if assignment is supported first then that assignment needs to have some
configuration associated with it as to which memory transactions are counted, no?

If I understand correctly MPAM would have hardcoded events (hardcoded which
transactions are counted by current default mbm_total_bytes and/or mbm_local_bytes).
The memory transactions that the event counts can be exposed in the
associated event_filter file. User space can use the per-resource group
mbm_L3_assignments file to assign the event to the resource group that will
result in counter allocated and programmed to count those transactions for
that resource group.

With only one bandwidth counter it will only be possible to assign one event to
one resource group at a time.

> 
>> display the existing event configuration and if user cannot modify it return
>> a failure when user attempts to do so?
> 
> I guess it could. Currently in MPAM we just support mbm_total_bytes and so it
> would always be 0x1F. Would we want some other way to indicate that it is fixed
> rather than trying to change it? However, if we just remove the configuration

event_filter could also be made readable only. This sounds temporary though and at
some point the MPAM driver will support event configuration. I thus do not think
resctrl fs should make big interface changes to accommodate this.

> files then it seems natural for mbm_total_bytes to just have the same meaning as
> it has when BMEC and ABMC are not enabled.

I do not see a reason to remove the configuration file. If MPAM just supports
mbm_total_bytes then user space can still look at its event_filter to see which
transactions are counted by it.  I am not sure about the 0x1F you mention (was
expecting 0x7F), but below is how it would appear:

  # cat /sys/fs/resctrl/info/L3_MON/event_configs/mbm_total_bytes/event_filter
  local_reads,remote_reads,local_non_temporal_writes,remote_non_temporal_writes,
  local_reads_slow_memory

Reinette