Hi Shanker, Fenghua,

On 2/2/26 16:34, Shanker Donthineni wrote:

Hi Ben,

On 2/2/2026 4:21 AM, Ben Horgan wrote:

quoted

External email: Use caution opening links or attachments


Hi Shanker,

On 1/31/26 02:30, Shanker Donthineni wrote:

quoted

Hi Ben,

On 1/30/2026 8:17 AM, Ben Horgan wrote:

quoted

External email: Use caution opening links or attachments


Hi Fenghua, Jonathan,

On 1/13/26 15:39, Jonathan Cameron wrote:

quoted

On Mon, 12 Jan 2026 16:59:08 +0000
Ben Horgan [off-list ref] wrote:

quoted

From: James Morse <james.morse@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.

quoted

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.

quoted

  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/ (local)

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