Re: [LSF/MM/BPF TOPIC] Improve this_cpu_ops performance for ARM64 (and potentially other architectures)

[Ryan Roberts <ryan.roberts@arm.com>]

On 17/02/2026 17:28, Christoph Lameter (Ampere) wrote:
> On Mon, 16 Feb 2026, Catalin Marinas wrote:
> 
>> It's not about TLB conflicts but rather using the wrong translation for
>> a per-CPU variable with CnP.
> 
> These conflicts could only come about if each PE would not be able to have
> its own page table but share page tables between processors.
> 
> That is not the case from what I can tell. The ARM64 code does not
> support a shared page table and if I remember right Windows actually requires a per
> processor page table.

Each PE is able to be configured to use it's own page table, I'm not denying
that. It is definitely possible to implement what you are proposing.

However, there is a feature called FEAT_TTCNP, which allows SW to hint to the PE
that the entries in it's pgtable are the same as entries in another PE's
pgtable. If the hint (bit 0 in TTBR1) is applied for multiple PEs, then those
PEs are permitted to share a TLB.

Today, if the kernel is compiled with CNP support and the CPU supports it, then
the bit is set.

AIUI, there are a number of CPUs out there that can share TLB to some extent and
do take advantage of this feature.

Your proposed per-CPU pgtable would be incompatible with CNP because if PE0 and
PE1 share a TLB, PE1 would end up miss-translating a per-CPU VA to PE0's copy if
PE0 previously accessed it and caused the (shared) TLB entry to be created.

So I believe there will be a performance cost for some CPUs if we take your
proposed approach and disable CNP. We would need to evaluate that cost and
decide which of the 2 mutually exclusive features provides the most value.

Thanks,
Ryan