Message-ID: <46047ccd-3b45-4bce-a71b-47dadc1eab88@arm.com>
Date: Thu, 15 Jan 2026 14:37:31 +0000
From: Ben Horgan <ben.horgan@....com>
To: Zeng Heng <zengheng4@...wei.com>, james.morse@....com
Cc: amitsinght@...vell.com, baisheng.gao@...soc.com,
 baolin.wang@...ux.alibaba.com, carl@...amperecomputing.com,
 catalin.marinas@....com, corbet@....net, dave.martin@....com,
 david@...nel.org, dfustini@...libre.com, fenghuay@...dia.com,
 gshan@...hat.com, joey.gouly@....com, jonathan.cameron@...wei.com,
 kobak@...dia.com, kvmarm@...ts.linux.dev, lcherian@...vell.com,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 maz@...nel.org, oupton@...nel.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,
 suzuki.poulose@....com, tan.shaopeng@...itsu.com, will@...nel.org,
 sunnanyong@...wei.com, Babu Moger <bmoger@....com>
Subject: Re: [PATCH RESEND v2 0/45] arm_mpam: Add KVM/arm64 and resctrl glue
 code

Hi Zeng,

+CC Babu (Comments on PLZA)

On 1/14/26 06:51, Zeng Heng wrote:
>> From: Ben Horgan <ben.horgan@....com>
>> Date: Fri, 19 Dec 2025 18:11:02 +0000
>> Subject: [PATCH v2 00/45] arm_mpam: Add KVM/arm64 and resctrl glue code
>>
>> One major departure from the previous snapshot branches referenced in the
>> base driver series is that the same MPAM setting are used for kernel-space
>> and user-space. That is, MPAM1_EL1 is set to the same value as MPAM0_EL1
>> rather than keeping the default value. The advantages of this are that it
>> is closer to the x86 model where the closid is globally applicable, all
>> partids are usable from user-space and user-space can't bypass MPAM
>> controls by doing the work in the kernel. However, this causes some
>> priority inversion where a high priority task waits to take a mutex held by
>> another whose resources are restricted by MPAM. It also adds some extra
>> isb(). I would be interested in opinions/data on the policy for MPAM in
>> kernel space, i.e how MPAM1_EL1 is set.
> 
> Another advantage is that, given the small size of the L2 cache,
> frequent switching of MPAM configurations between kernel and user modes
> can cause cache-capacity jitter, making it difficult to isolate
> interference from noisy neighborhood.
> 
> However, in addition to the issues mentioned above, updating the
> MPAM1_EL1 configuration also exposes interrupt handling to the MPAM
> settings of the current task.

Makes sense, thanks for these two observations.

> 
> I still agree with the current modification of setting MPAM1_EL1 to the
> same value as MPAM0_EL1. However, the ARM MPAM hardware supports more
> flexible configuration schemes than x86 RDT and another approach is also
> worth considering: Software can let a control group choose whether
> kernel mode follows the user mode MPAM settings, or whether the kernel
> mode configuration is delegated to the default control group, though
> this may change the existing user interface.

I wonder if this would be possible in AMD PLZA as well. Babu?

> 
> At the LPC resctrl micro-conference, Babu also mentioned the PLZA proposal
> as an attempt to address the issues raised above. Seems like no clear
> interface was presented yet. Wait to see what new interface that solution
> will introduce.

Yes, I watched a recording of that. :)

> 
> One last thing, please add me to the CC list for future MPAM patch series.
> I'll provide timely testing on my local aarch64 environment and review
> feedback. Thanks.

Will do. Apologies for not doing this earlier and thank you for the
promise of testing and reviews :) There is a v3 which you have hopefully
seen.

> 
> 
> Best Regards,
> Zeng Heng
> 
> 

Thanks,

Ben

Powered by blists - more mailing lists