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

[Catalin Marinas <catalin.marinas@arm.com>]

On Fri, Feb 13, 2026 at 10:42:21AM -0800, Yang Shi wrote:
> On Thu, Feb 12, 2026 at 10:42 AM Ryan Roberts <ryan.roberts@arm.com> wrote:
> > On 11/02/2026 23:14, Yang Shi wrote:
> > > So, the code flow should just become:
> > > INC VIRTUAL_BASE + percpu_variable_offset
> > >
> > > In order to do that we need to have the same virtual address mapped
> > > differently for each processor. This means we need different page
> > > tables for each processor. These page tables
> > > can map almost all of the address space in the same way. The only area
> > > that will be special is the area starting at VIRTUAL_BASE.
> >
> > This is an interesting idea. I'm keen to be involved in discussions.
> >
> > My immediate concern is that this would not be compatible with FEAT_TTCNP, which
> > allows multiple PEs (ARM speak for CPU) to share a TLB - e.g. for SMT. I'm not
> > sure if that would be the end of the world; the perf numbers below are
> > compelling. I'll defer to others' opions on that.
> 
> Thank you for involving the discussion. The concern is definitely
> valid. The shared TLB sounds like a microarchitecture feature or
> design choice. AmpereOne supports CNP, but doesn't share TLB. As long
> as it doesn't generate TLB conflict abort, shared TLB should be fine,
> but may suffer from frequent TLB invalidation. Anyway I think it
> should be solvable. We can make percpu page table opt-in if the
> machines can handle TLB conflict, just like what we did for
> bbml2_noabort.

It's not about TLB conflicts but rather using the wrong translation for
a per-CPU variable with CnP.

-- 
Catalin