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

[Yang Shi <yang@os.amperecomputing.com>]

On 2/16/26 3:39 AM, Catalin Marinas wrote:
> 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.

Ah, yes. It may be just a simple TLB hit for the other CPU due to the 
same virtual address is used if TLB is shared.