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

[Ben Horgan]

Hi Reinette,

On 3/4/26 17:03, Reinette Chatre wrote:
> 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? 

Yes, it's not important, but I was just wondering if the telemetry
monitoring feature had the same counter scarcity problem that the
counter assignment feature addresses and if it was solved in the same
way. Although, I realise it may just be to do with the number of rmid
supported for telemetry.

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

Let's concentrate on the other thread, but no. The MSC.RIS count single
source and the driver only ever sums equivalent parts within a
component. (I guess the hardware counters could be implemented using
accumulation but, that's not our concern.)

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

We mainly talk about the placement of the MSC rather than bandwidth
types. For mbm_total_bytes I'm just viewing that as all reads/writes
leaving the L3. Bringing in the extra info temporal/slow_memory is just
extra. Still, should be ok.

> 
> Reinette
> 

-- 
Thanks,

Ben