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

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.

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.

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.

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.

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.

               Linus