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

[Shanker Donthineni]

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)

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.

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

Thanks,
Shanker