Hi Carl,
On 11/7/25 23:22, Carl Worth wrote:
> Ben Horgan <ben.horgan@arm.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@arm.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