[PATCH v3 41/47] arm_mpam: Generate a configuration for min controls

[Ben Horgan]

Hi Shanker, Fenghua,

On 2/2/26 16:34, Shanker Donthineni wrote:
> Hi Ben,
> 
> On 2/2/2026 4:21 AM, Ben Horgan wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> Hi Shanker,
>>
>> On 1/31/26 02:30, Shanker Donthineni wrote:
>>> Hi Ben,
>>>
>>> On 1/30/2026 8:17 AM, Ben Horgan wrote:
>>>> External email: Use caution opening links or attachments
>>>>
>>>>
>>>> Hi Fenghua, Jonathan,
>>>>
>>>> On 1/13/26 15:39, Jonathan Cameron wrote:
>>>>> On Mon, 12 Jan 2026 16:59:08 +0000
>>>>> Ben Horgan <ben.horgan at arm.com> wrote:
>>>>>
>>>>>> From: James Morse <james.morse at arm.com>
>>>>>>
>>>>>> MPAM supports a minimum and maximum control for memory bandwidth. The
>>>>>> purpose of the minimum control is to give priority to tasks that are
>>>>>> below
>>>>>> their minimum value. Resctrl only provides one value for the
>>>>>> bandwidth
>>>>>> configuration, which is used for the maximum.
>>>>>>
>>>>>>
>>>>>> Hence, I'll drop this patch, and update the mbw_min default to be
>>>>>> 0xFFFF
>>>>>> and for the value not to change even if mbw_max changes. I think this
>>>>>> leaves us in the best position going forward without any heuristics
>>>>>> that
>>>>>> may come back to bite us later when proper support for a schema
>>>>>> supporting mbw_min is added to resctrl.
>>> Background: I previouslyshared original fix(seecodesnippet below) with
>>> James Morse
>>> ~2 years ago to address the errata, which explicitly recommends usinga
>>> 5% gap for
>>> mitigation of the Hardware issue (the problem described in commit text
>>> of T241-MPAM-4)
>>>
>>> For some reason theoriginalimplementationwas splitinto two patches:
>>>    - Generic change applicable toall chips
>>>    - Specific fixfor Graceerrata T241-MPAM-4
>>> Issue: Dropping this patch impacts[PATCH v3 45/47] forthe errata fix. If
>>> removalis
>>> necessary, please mergethis changeinto the T241-MPAM-4-specific patch.
>>
>> What's the behaviour on T241 when MBW_MIN is always 0xFFFF?
> 
> Memory bandwidth throttling will not function correctly. The MPAM hardware
> monitors MIN and MAX values for each active partition to maintain memory
> bandwidth usage between MBW_MIN and MBW_MAX. Therefore, MBW_MIN must be
> less than MBW_MAX (IMO, setting MBW_MIN to always 0xFFFF is incorrect)

Ah, yes. 0xFFFF is indeed a bad default. Looking at Table 5-3 in Mpam
system component B.a I see that as all bandwidth will be below the
minimum and so high preference the MBW_MAX will have no effect. I'll
keep the default for MBW_MIN as 0 (or the minimum for grace).

> 
> Grace errata T241-MPAM-4 has two issues:
> - MBW_MIN must be greater than 0 (WAR set to one when when it's zero) -
> In the Grace implementation of memory-bandwidth partitioning (MPAM),
>    in the absence of contention for bandwidth, the minimum bandwidth
>    setting can affect the amount of achieved bandwidth. Specifically,
>    the achieved bandwidth in the absence of contention can settle to any
>    value between the values of MIN and MAX. This means if the gap between
>    MIN and MAX is large then the BW can settle closer to MIN. To achieve
>    BW closer to MAX in the absence of contention, software should configure
>    a relatively narrow gap between MPAMCFG_MBW_MIN and MPAMCFG_MBW_MAX.
>    The recommendation is to use a 5% gap, corresponding to an absolute
>    difference of (0xFFFF * 0.05) = 0xCCC between MPAMCFG_MBW_MIN and
>    MPAMCFG_MBW_MAX.

Ok, thanks. I understand the issue more now.

> 
>> I'm worried if we make a policy decision of how to set MBW_MIN based on
>> MBW_MAX for this platform then we won't be able to support a
>> configurable MBW_MIN in the future for this platform.
> 
> Yes, we can't support generic programmable MBW_MIN for Grace chip. The
> currentresctrl interface doesnot exposeMBW_MIN, preventingusers from
> configuring the recommended5% gap. Without this interfacesupport,
> theonly wayto applytheworkaround is through driver-level changes.
> 
>>   As when MBW_MIN
>> support is added in resctrl the user's configuration for this platform
>> would change meaning on kernel upgrade.
> 
> What is the timelineforaddingMBW_MIN support? We have two options.
>  Option-A: Keep the current WAR 5% gap and don't allow users to program
> MBW_MIN.
>  Option-B:Remove the5% gap workaround and relyon usersto program MBW_MIN
>             accordingto the Grace recommendations
> whentheinterfacebecomes available.
> 
> We'll prefer option-B.

The problem with option-B is that the transition introduces a change in
user visible
for any existing MBW_MAX configuration.

If option-A is preferable to disabling MBW_MAX on grace until we have
proper MBW_MIN support in resctrl then I think we should assume option-A.

The work to decide how new schema is underway but it's difficult to say
how long it will take.
See: https://lore.kernel.org/lkml/aPtfMFfLV1l%2FRB0L@e133380.arm.com/

Assuming that you're sure that the 5% gap is the best policy and that
there are no other objections I'll add that policy back into the
T241-MPAM-4 workaround and look into a way to ensure that we don't
accidentally enable MBW_MIN support for grace comes when the proper
support is added.

> 
> Thanks,
> Shanker
> 

Thanks,

Ben