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

[Reinette Chatre <reinette.chatre@intel.com>]

Hi Ben,

On 3/4/26 3:31 AM, Ben Horgan wrote:
> Hi Reinette,
> 
> On 3/3/26 18:14, Reinette Chatre wrote:
>> 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.
> 
> That's right.
> 
> Just wondering, why aren't there <telemetry>_L3_assignments files to
> allow keeping all CTRL_MON/MON groups when there are, as pointed out in
> the Documentation/filesystems/resctrl.rst, platforms with limited
> telemetry counters?

Apologies but I do not understand this question. Are you referring to the new
telemetry monitoring feature? 

>> With only one bandwidth counter it will only be possible to assign one event to
>> one resource group at a time.
> 
> yes
> 
>>
>>>
>>>> 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.
> 
> For MPAM, some of the bits will always be unchangeable as they depend on
> which hardware counter rather than the configuration of that hardware
> counter. Also, not all MPAM hardware supports the read/write configuration.

This seems to tie in with discussion in other thread on how values for
mbm_total_bytes and mbm_local_bytes are computed. It almost sounds as though there
is just one bandwidth measurement returned from the various counters on the system
and that MPAM driver uses system knowledge to accumulated needed values and display
them to user space as these separate events.

>>> 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:
> 
> 0x1F was a mistake, it is indeed 0x7F.
> 
>>
>>   # 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
> 
> Ok, it's not a natural description for MPAM bandwidth counters but I
> think we can live with that.

What are the MPAM descriptions?

Reinette