[RFC v2 PATCH 0/16] Optimize this_cpu_*() ops for non-x86 (ARM64 for this series)

[Will Deacon]

On Tue, Aug 04, 2026 at 06:23:48PM +0100, Lorenzo Stoakes (ARM) wrote:
> On Tue, Aug 04, 2026 at 09:30:08AM -0700, Linus Torvalds wrote:
> > On Tue, 4 Aug 2026 at 09:27, Christoph Lameter (Ampere) <cl at gentwo.org> wrote:
> > >
> > > We certainly do not want to replicate that approach. We are using the per
> > > cpu page tables to avoid address calculations in the VM that other
> > > platforms can do with a segment override.
> >
> > Right, and I said that that's ok as long as it's a internal
> > architecture thing. Not a "this is how the VM works".
> >
> > Because people really have wanted to make it a "this is how the VM
> > works" thing. And that is very much what I object to.
> 
> Well :) it fundamentally changes how mm works - now we have a whole new set of
> kernel page tables and PGD's that we have to think about.
> 
> And the series either tries to hack changes that fundamentally alter how
> vmalloc works or will add its own duplicative kernel page table code to do the
> same kind of thing.
> 
> So now core mm has to worry about TLB coherency and synchronisation, how this
> might interact with things like page table isolation, and a lot of other
> headaches (and I'm not really convinced they've been thought through here).
> 
> IOW - breaking fundamental assumptions about kernel page tables is inherently a
> whole-VM change (See [0] for instance for an example of what can go wrong).
> 
> If Christoph + Yang can provide compelling data that advocates for this change
> AND the core mm and arm64 communities agree to move forward with this, then
> things are different.
> 
> However, I think the best approach here is to find the least invasive way of
> limiting the change to the architecture itself.
> 
> Mark has put forward an approach that eliminates the exact overhead that this
> series aims to address but does so without having to fundamentally alter core
> mm assumptions (v2 posted at [1]).
> 
> So that seems very clearly to be a better alternative to me.
> 
> Ultimately we need mm and arm64 maintainer agreement on the way forwards (or in
> the case of a truly isolated arm64 solution, arm64 maintainer agreement).

So the nice thing about having two implementations (i.e. the per-cpu
page-tables *and* the preemption stuff from Mark) is that we can pitch
them against each other to help us make a decision.

However, I don't see how anybody could argue that Mark's series isn't
cleaner and easier to maintain. I've seen it described as "hacky" but I
can't tell whether or not that's supposed to be a criticism. If we
seriously want to consider the per-cpu page-table approach on arm64, the
numbers need to be _really_ good and across a variety of hardware, not
just the stuff with a memory system made of baling twine. That extends
to the kernel text replication efforts too.

Will