linux-kernel - Re: [PATCH v3 41/47] arm_mpam: Generate a configuration for min controls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <80db7035-07d3-4fb4-a228-f9c67d2df1f4@arm.com>
Date: Fri, 30 Jan 2026 14:17:38 +0000
From: Ben Horgan <ben.horgan@....com>
To: Jonathan Cameron <jonathan.cameron@...wei.com>,
 "fenghuay@...dia.com" <fenghuay@...dia.com>
Cc: amitsinght@...vell.com, baisheng.gao@...soc.com,
 baolin.wang@...ux.alibaba.com, carl@...amperecomputing.com,
 dave.martin@....com, david@...nel.org, dfustini@...libre.com,
 fenghuay@...dia.com, gshan@...hat.com, james.morse@....com,
 kobak@...dia.com, lcherian@...vell.com,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 peternewman@...gle.com, punit.agrawal@....qualcomm.com,
 quic_jiles@...cinc.com, reinette.chatre@...el.com, rohit.mathew@....com,
 scott@...amperecomputing.com, sdonthineni@...dia.com,
 tan.shaopeng@...itsu.com, xhao@...ux.alibaba.com, catalin.marinas@....com,
 will@...nel.org, corbet@....net, maz@...nel.org, oupton@...nel.org,
 joey.gouly@....com, suzuki.poulose@....com, kvmarm@...ts.linux.dev,
 Zeng Heng <zengheng4@...wei.com>
Subject: Re: [PATCH v3 41/47] arm_mpam: Generate a configuration for min
 controls

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@....com> wrote:
> 
>> From: James Morse <james.morse@....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.
>>
>> The minimum control is always programmed to zero on hardware that supports
>> it.
>>
>> Generate a minimum bandwidth value that is 5% lower than the value provided
>> by resctrl. This means tasks that are not receiving their target bandwidth
>> can be prioritised by the hardware.
>>
>> For component reset reuse the same calculation so that the default is a
>> value resctrl can set.
>>
>> CC: Zeng Heng <zengheng4@...wei.com>
>> Signed-off-by: James Morse <james.morse@....com>
>> Signed-off-by: Ben Horgan <ben.horgan@....com>
> 
> I'm interested to see how this plays out as a default choice
> vs what people elect to run.  Seems harmless to start with this.

I've realised it's not harmless :(

> 
> Reviewed-by: Jonathan Cameron <jonathan.cameron@...wei.com>
> 

In the discussion on a platform quirk, arm_mpam: Add workaround for
T241-MPAM-4,  Fenghua raised the following issues.

"
MBW_MIN is 1% or 5% less than MBW_MAX.

The lower MBW_MIN hints hardware to lower mem bandwidth when mem access
contention. That causes memory performance degradation.

Is it possible to do the following changes to fix the performance issue?
1. By default min mbw is equal to max mbw. So hardware won't lower
performance unless it's needed. This can fix the current performance issue.
2. Add a new schemata line (e.g. MBI:<id>=x;<id>=y;...) to specify min
mbw just like max mbw specified by schemata line "MB:...". User can use
this line to change min mbw per partition per node. This could be added
in the future.
"

On 1.
Thinking about this again, I think adding any heuristic tied to mbw_max
to determine what mbw_min is undesirable. Loading the mpam driver or
mounting resctrl shouldn't change the defaults away from the defaults
for h/w partid 0 or performance characteristics may change unexpectedly.
The spec only gives us suggestions for these but we should go with
those. See table 3.8 in IH0099B.a Mpam System Component Specification.
The MBW_MIN that is 0xFFFF. Also, having mbw_min doesn't necessarily
mean that there is mbw_max. A system that doesn't advertise mbw_min
support to the user should act as if there is no mbw_min support.
On 2.
Yes, adding a new user interface in resctrl is the way to deal with
this. See [1] for a discussion on adding new schema.

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.

[1] https://lore.kernel.org/lkml/aPtfMFfLV1l%2FRB0L@e133380.arm.com/

Thanks,

Ben