Message-ID: <3db645f5-b0bf-44a0-9cdc-460e46ec7bc2@arm.com>
Date: Mon, 10 Nov 2025 16:15:58 +0000
From: Ben Horgan <ben.horgan@....com>
To: Carl Worth <carl@...amperecomputing.com>, james.morse@....com
Cc: amitsinght@...vell.com, baisheng.gao@...soc.com,
 baolin.wang@...ux.alibaba.com, bobo.shaobowang@...wei.com,
 catalin.marinas@....com, dakr@...nel.org, dave.martin@....com,
 david@...hat.com, dfustini@...libre.com, fenghuay@...dia.com,
 gregkh@...uxfoundation.org, gshan@...hat.com, guohanjun@...wei.com,
 jeremy.linton@....com, jonathan.cameron@...wei.com, kobak@...dia.com,
 lcherian@...vell.com, lenb@...nel.org, linux-acpi@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 lpieralisi@...nel.org, peternewman@...gle.com, quic_jiles@...cinc.com,
 rafael@...nel.org, robh@...nel.org, rohit.mathew@....com,
 scott@...amperecomputing.com, sdonthineni@...dia.com, sudeep.holla@....com,
 tan.shaopeng@...itsu.com, will@...nel.org, xhao@...ux.alibaba.com
Subject: Re: [PATCH 00/33] arm_mpam: Add basic mpam driver

Hi Carl,

On 11/7/25 23:22, Carl Worth wrote:
> Ben Horgan <ben.horgan@....com> writes:
>> This version of the series comes to you from me as James is otherwise
>> engaged. I hope I have done his work justice. I've made quite a few
>> changes, rework, bugs, typos, all the usual. In order to aid review,
>> as Jonathan suggested, I've split out some patches and made an effort
>> to minimise the amount of churn between patches.
> 
> I've built this and booted on an Ampere system. It ends up reporting a
> successful message of:
> 
> 	MPAM enabled with 1 PARTIDs and 1 PMGs
> 
> So the code seems happy enough as far as that goes.
> 
> But the expected number of PARTIDs on this system is much larger than 1,
> (MPAM with a single PARTID would not be useful at all).
> 
>> See below for a public branch. No public updated version of the
>> snapshot (the rest of the driver) I'm afraid.
> 
> Looking closer, it looks like the bogus value of 0 for mpam_partid_max
> is because the following patch (which does appear in James' various
> snapshots) isn't present yet in the code submitted to this point:
> 
> 	commit 33c1f50970917ac9f2a8e224d850936374df6173
> 	Author: James Morse <james.morse@....com>
> 	Date:   Fri Jul 4 14:22:30 2025 +0100
> 	
> 	    arm64: mpam: Advertise the CPUs MPAM limits to the driver
> 	    
> 	    Requestors need to populate the MPAM fields on the interconnect. For
> 	    the CPUs these fields are taken from the corresponding MPAMy_ELx
> 	    register. Each requestor may have a limit on the largest PARTID or
> 	    PMG value that can be used. The MPAM driver has to determine the
> 	    system-wide minimum supported PARTID and PMG values.
> 	    
> 	    To do this, the driver needs to be told what each requestor's
> 	    limit is.

Yes, the driver does barely anything without a requestor.

> 
> So, I guess I'm wondering what more I could do to test this code at this
> point, prior to merging it.
> 
> I'm very interested in seeing this code land upstream as soon as
> possible, and I've got access to an implementation to test whatever I
> can.
> 
> So let me know what else I can do and I'll be glad to contribute my
> Tested-by when I've done it.
> 
> -Carl

Thanks for the quick response and testing.

I've just responded to the cover letter with a branch containing the
rest of the driver. (Just so it's not hidden in this thread) It's
https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git/log/?h=mpam/snapshot/v6.18-rc4

With that, you should be able to enable all usable PARTID and PMG, mount
resctrl, add tasks/cpus to resctrl control groups, run benchmarks to
check that the controls are respected and check that the monitors give
expected values.

Thanks,

Ben

Powered by blists - more mailing lists