Message-ID: <3d14457d-a510-45b0-811f-347aac5cfda8@arm.com>
Date: Thu, 5 Feb 2026 14:37:03 +0000
From: Ben Horgan <ben.horgan@....com>
To: Jonathan Cameron <jonathan.cameron@...wei.com>,
 Linus Walleij <linusw@...nel.org>
Cc: Yushan Wang <wangyushan12@...wei.com>, alexandre.belloni@...tlin.com,
 arnd@...db.de, fustini@...nel.org, krzk@...nel.org,
 linus.walleij@...aro.org, will@...nel.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 fanghao11@...wei.com, linuxarm@...wei.com, liuyonglong@...wei.com,
 prime.zeng@...ilicon.com, wangzhou1@...ilicon.com, xuwei5@...ilicon.com,
 linux-mm@...r.kernel.org, SeongJae Park <sj@...nel.org>,
 reinette.chatre@...el.com, james.morse@....com,
 Zeng Heng <zengheng4@...wei.com>, Tony Luck <tony.luck@...el.com>,
 Dave Martin <Dave.Martin@....com>, Babu Moger <babu.moger@....com>
Subject: Re: [PATCH 1/3] soc cache: L3 cache driver for HiSilicon SoC

On 2/5/26 10:18, Jonathan Cameron wrote:
> On Thu, 5 Feb 2026 10:12:33 +0100
> Linus Walleij <linusw@...nel.org> wrote:
> 
>> Hi Jonathan,
>>
>> thanks for stepping in, I'm trying to be healthy sceptical here...
>>
>> What you and others need to do is to tell me if I'm being too
>> critical. But right now it feels like I need some more senior
>> MM developers to tell me to be a good boy and let this
>> hack patch slip before I shut up ;)
> 
> It's good to have these discussions as it makes us actually
> explain what they want to do much more clearly!
> wangyushan and I have both been taking about this for too long so
> it's easy to miss that it's not been explained properly.
> 
> Note I was absolutely expecting a non trivial discussion on how to do
> this and in particular how generic it should be.
>  
> +CC a various resctl / mpam related people.
[...]
> 
>>
>> But does the developer know if that hard kernel is importantest
>> taken into account all other processes running on the system,
>> and what happens if several processes say they have
>> such hard kernels? Who will arbitrate? That is usually the
>> kernels job.
> 
> Take the closest example to this which is resctl (mpam on arm).
> This actually has a feature that smells a bit like this.
> Pseudo-cache locking. 
> 
> https://docs.kernel.org/filesystems/resctrl.html#cache-pseudo-locking
> 
> My understanding is that the semantics of that don't align perfectly
> with what we have here.  Yushan can you add more on why we didn't
> try to fit into that scheme?  Other than the obvious bit that more
> general upstream support for the arch definitions of MPAM is a work in
> progress and fitting vendor specific features on top will be tricky
> for a while at least.  The hardware here is also independent of the
> MPAM support.
> 
> Resctl puts the control on resource allocation into the hands of
> userspace (in that case via cgroups etc as it's process level controls).
> The cache lockdown is a weird because you have go through a dance of
> creating a temporary setup, demand fetching the lines into cache and
> then rely on various operations not occuring that might push them out
> again.
> 
> Resctl provides many footguns and is (I believe) used by administrators
> who are very careful in how they use it.  Note that there are some guards
> in this new code to only allow locking a portion of the l3. We also rely
> somewhat on the uarch and cache design to ensure it is safe to do this
> type of locking (other than reducing perf of other tasks).
> I'm dancing around uarch details here that I would need to go seek
> agreement to share more on.
> 

Just wondering about the compatiblity of cache lockdown and
resctrl/mpam. If this is done outside resctrl then how would this
interact with the cache portion bitmaps used in resctrl/mpam? For
instance, how would a user know whether or not a resctrl/mpam cache
portion is unusable because it has been locked?
Thanks,

Ben

Powered by blists - more mailing lists