Message-ID: <CAD++jLkVoorGWceRaF0VNeNLQz8TM1p2Dz-ivgyr4_T_QB_wfg@mail.gmail.com>
Date: Thu, 5 Feb 2026 14:47:31 +0100
From: Linus Walleij <linusw@...nel.org>
To: Jonathan Cameron <jonathan.cameron@...wei.com>
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>, ben.horgan@....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 Thu, Feb 5, 2026 at 11:18 AM Jonathan Cameron
<jonathan.cameron@...wei.com> wrote:

> 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

That was very interesting. And more than a little bit complex.
IIUC MPAM is mostly about requesting bandwidth to/from the
memory.

But maybe cache lockdown can build on top?

> I'm also not sure what appetite there will be for an madvise()
> for something that today we have no idea if anyone else actually
> has hardware for.  If people do, then please shout and we can
> look at how something like this can be generalized.

Cache lockdown is an ages old concept, I think others can do
it too, you are just the first to try to support it upstream.
Personally I'm all for this, as long as we can come up with
something generic for others to use as well. No custom device
+ ioctl stuff.

There are adjacent stuff that vendors are doing is about prefetch
and which I mentioned briefly:

Fujitus prefetch:
https://lore.kernel.org/linux-arm-kernel/20220607120530.2447112-1-tarumizu.kohei@fujitsu.com/

AmpereOne prefetch:
https://lore.kernel.org/linux-arm-kernel/20231122092855.4440-1-shijie@os.amperecomputing.com/

Maybe that is more related to MPAM actually. What it has in common
with cache lockdown is "significatly indicate memore areas of special
interest". But notice Will Deacons reply:
https://lore.kernel.org/linux-arm-kernel/ZV3omRGtVS9l-tKk@FVFF77S0Q05N/

 "We tend to shy away from micro-architecture specific optimisations in
 the arm64 kernel as they're pretty unmaintainable, hard to test properly,
 generally lead to bloat and add additional obstacles to updating our
 library routines."

> My current thinking is first come first served with a path to
> clearly tell an application it didn't get what it wanted.
> Scheduling, priority etc being involved would all interfere
> with the strong guarantees lock down provides.

That sounds more like mdemand() than madvise() doesn't it ;)

But surely an all-or-nothing ABI can be specified, and maybe
a please-if-you-can ABI as well.

> > MM might want to use that information for other things.
>
> Absolutely, though I'm doubtful about trying to design a generic
> way of conveying latency criticality without knowing more of those
> use cases from the start.

Well, abstracting is about boiling the world down to a few facts
that can be used for making general decisions.

But for one I suppose if someone locks down some cache lines
in L3 and then not actually use them much at long intervals
because of misc, I suppose it's not very nice if the kernel decide
to swap out the page with these cache lines in it, because that
would have adverse impact on the performace once it hits for example?

Or did someone think about that already? Is that avoided in the
current patch set? (Maybe a stupid question...)

Likewise I see that this code is keeping track of which CPU
the l3 cache line were locked from, but I don't see anything in
this code blocking task migration for whoever called this ABI
or am I wrong? What happens if the scheduler moves the
process to another CPU? Or is it implicit that this is nailed to
the current CPU? Then surely that need to be enforced?

I just get the overall feeling that this was just tested on a scenario
such as:

1. Boot
2. Run a process calling this code, hey it works
3. Terminate process

No sleeping and swapping under memory pressure etc happing.

Designing for the generic case and in a central part of the kernel
(inside MM not in drivers/soc...) would avoid such snags I think.

Yours,
Linus Walleij

Powered by blists - more mailing lists