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

On Tue, 4 Aug 2026, Linus Torvalds wrote:

> On Tue, 4 Aug 2026 at 07:15, Lorenzo Stoakes (ARM) <[email protected]> wrote:
> >
> > Linus - I assume you still find per-cpu page tables totally unacceptable? (had a
> > look around to see your take on this recently and found [0] which seems to
> > confirm it :)
>
> Yes, I still think that per-cpu page tables as some kind of
> architectural design is a horrible idea, because it paints us into a
> corner where you have intentional duplication and then end up having
> to have coherency issues where you need to lock for updates just to
> keep things in sync - and may need to do extra work on hardware that
> may otherwise already have hardware coherency support.

We already have had the intentional duplication, meaning multiple
virtual  addresses  for a single physical address with vmalloc and with
vmemmap for a very long time. Issues with hardware coherency that may have
existed for these cases have been fixed a long time ago.

> I honestly think that people who think that cache coherency in
> software is a great idea in general are misguided and should not work
> on kernels, but should go back to eating crayons and decide if purple
> tastes better than yellow.

Certain a bad idea. The per cpu pagew tables do not rely on cache
coherency in software.

> That said - per-cpu page tables as some kind of internal architecture
> choice that limits the damage to some simpler case is not necessarily
> wrong. We've obviously done things like that for page table isolation
> etc. It can be horribly expensive, but sometimes that is the price you
> are willing to pay - and sometimes you can avoid the expense entirely
> by knowing how the particular hardware works.

Have the same virtual address on all processors to reach the local per cpu
instance of a variable simplifies kernel code and avoids
preempt_enable/disable sections. Especially operations on counters in the
VM become much more efficient.

X86 can accomplish that with a segment override. That is not available on
other platforms. Page tables can be used to do the proper mapping so that
kernel code does not have to theses address calculations. These are
frequent operations in the kernel memory management.


> Very specific example: on 32-bit x86 with PAE, the top-level page
> table directory is fundamentally per-cpu in nature. It's just four
> entries that get loaded into the CPU on page table load, but it means
> that you can do things like having one quarter of the page tables be
> per-cpu, and the rest be shared. Several other architectures have
> similar "regions". So it can be an architectural choice to have some
> kind of per-cpu TLB. But I absolutely do *not* want to see a model
> where the general MM layer dictates that design.

X86 creates highly optimized code for per cpu operations without preempt
enable/disable sections and I hope its ok to use per cpu page table to get
to a similar degress of compactness and performance on ARM64.

> And there are historical reasons to really hate it. Plan-9 had a
> completely broken threading model that depended on per-thread page
> tables. It was literal garbage. It was broken beyond words exactly due
> to coherency issues, and I still do not understand how otherwise very
> smart people ever came up with such a stupid idea.
>
> We are not making _that_ mistake. We have made enough other ones to
> not neet to shoot ourselves in the head that badly.

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.