Re: [PATCH v2 4/6] fs/resctrl: Disallow the software controller when mbm counters are assignable
From: Ben Horgan
Date: Wed Mar 18 2026 - 11:54:57 EST
Hi Reinette,
On 3/17/26 17:17, Reinette Chatre wrote:
> Hi Ben,
>
> On 3/17/26 4:13 AM, Ben Horgan wrote:
>> Hi Reinette,
>>
>> On 3/16/26 21:35, Reinette Chatre wrote:
>>> Hi Ben,
>>>
>>> On 3/13/26 10:45 AM, Ben Horgan wrote:
>>>> The software controller requires that there are free running mbm counters
>>>
>>> How is "free running" defined?
>>
>> I mean that for each control group (and it's associated monitor groups) there are
>> dedicated MBM counters which are always present and always counting.
>> So, mon_event_count() always provides a value representative of the traffic
>> for that control group.
>
> This would be easier to parse if it was specific. For example, consider:
> "there is one MBM counter per monitor group that is assigned to the event backing
> the software controller (per mba_MBps_event)"
>
>>> (sidenote: please use upper case for acronyms throughout: mbm -> MBM)
>>
>> Ack
>>
>>>
>>>> for each control group in order to provide the feedback necessary to
>>>> control the memory bandwidth allocation for that control group. Previous
>>>> to the introduction counter assignment support (ABMC) resctrl required this
>>>
>>> I am not able to parse this second sentence. "to the introduction" -> "to
>>> the introduction of"? What does "this" refer to?
>>
>> The 'this' was referring to the first sentence, that you need dedicated counters.
>
> So "free running" means "dedicated"?
Yes, continually running and counting the same thing.
>
>>>> in order to advertise support for mbm but now if the mbm counters are
>>>> assignable then this can't be guaranteed.
>>>>
>>>> Currently, only AMD systems support counter assignment but the MBA is non
>>>> linear and so the software controller is never supported anyway. For MPAM
>>>> systems the MBA is linear and so the dependency on counters not being
>>>> assignable needs to made explicit. Hence, fail the mount if the user
>>>
>>> It is not clear to me that software controller depends on counters not being
>>> assignable. Is the problem not instead that the current implementation does not
>>> support this since it allows the event used by software controller to not have a
>>> counter assigned? So, instead of adding support for software controller by ensuring
>>> that the event used by software controller has a counter assigned, this patch opts
>>> for the simpler disabling of software controller when assignable counters are in use?
>>
>> Yes, they are not fundamentally incompatible but it would require some changes
>> to the resctrl interface. Unless there are sufficient counters to have one per monitor
>> group it will always be the case that creating more groups will lead to missing a counter
>> for the software controller on one of the control groups. As I understand it, resctrl
>> doesn't have a way to indicate that you only get a control on certain control groups.
>
> No, resctrl does not have a way to indicate that you only get a control on certain control
> groups but I do not think this is relevant. The user provides the mba_MBps mount option and
> that is when resctrl creates all files that includes automatic counter assignment, currently
> only based on rdt_resource::resctrl_mon::mbm_assign_on_mkdir.
> The dynamic assignment could take the software controller into account and fail the mount
> if counters needed by software controller cannot be assigned. Similarly, counter assignment
> done after mount can take software controller into account to ensure the event used by software
> controller always has a counter assigned.
>
> I am not advocating for this support but instead noting that I do think that it is possible
> to support software controller with assignable counters. If instead you still find that this
> is a use case that you prefer not to support in MPAM then that is of course fine. When doing so
> please let changelog be accurate regarding the choices instead of claiming MPAM cannot use software
> controller because of assignable counters.
>
> If you prefer this way then I think most accurate from resctrl fs perspective would be that the
> mount should instead check whether assignable counter mode is *enabled* as opposed to supported
> as this patch does, no? I understand this adds complexity since this would need to consider the
> scenario where user space may later enable assignable counters after mounting resctrl with
> software controller enabled though. It seems MPAM is attempting minimal resctrl changes to
Would disabling switching to mbm_event mode when the software controller is enabled be ok?
> reach a specific goal by using some generic motivations in changelog that are not accurate.
Apologies if the commit message aren't clear. I do see that I was confused in this one between
counters being assignable, i.e. mbm_event mode possible, and the user being the being able to
assign and unassign counters, i.e. mbm_event mode enabled. Do you prefer this as a commit message?
fs/resctrl: Disallow the software controller when using mbm_event mode
The software controller requires that there is one MBM counter, for each
domain, per monitor group that is assigned to the event backing the
software controller (the mba_MBps_event). When mbm_event mode is in use
this event backing cannot be guaranteed as there may be insufficient
counters, the user may unassign the counter or mbm_assign_on_mkdir may be
set to 0.
Currently, only AMD systems support counter assignment but the MBA is non
linear and so the software controller is never supported anyway. For MPAM
systems the MBA is linear and it could support the software controller.
Adding support would require guaranteeing that the events backing the
software controller are always assigned. In order to support mbm_event mode
for MPAM, which is needed to support memory bandwidth monitors, MBM, on
platforms with fewer bandwidth counters (per domain) than monitor groups,
take the pragmatic approach and fail the mount if the user requests the
software controller, the mba_MBps option, when the mbm_event mode is
enabled. Furthermore, disable switching to mbm_event mode when the software
controller is enabled. If, in the future, a way for mbm_event mode and the
software controller to function at the same time is introduced these
restrictions can be adapted.
>
> Finally, considering the message to user space:
> "mba_MBps requires dedicated MBM counters and linear scale MBA at L3 scope"
> upon reading above a user may attempt to explore how to solve the mount issue by fulfilling
> the requirement of "dedicated MBM counters". How should a user interpred "dedicated MBM counters"?
> It may be confusing to a user when a system indeed has sufficient counters but the mount
> still fails.
>
> How about instead something like below:
> "mba_MBps requires MBM (assignable counters not supported) and linear scale MBA at L3 scope"
> it is quite long so open to ideas.
How about mentioning the mbm_assign_mode to be more explicit. Maybe this?
"mba_MBps requires MBM (mbm_event mode not supported) and linear scale MBA at L3 scope"
>
> Reinette
>