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

[Tejun Heo <tj@kernel.org>]

Hello,

On Wed, Feb 11, 2026 at 03:14:57PM -0800, Yang Shi wrote:
...
> Overhead
> ========
> 1. Some extra virtual memory space. But it shouldn’t be too much. I
> saw 960K with Fedora default kernel config. Given terabytes virtual
> memory space on 64 bit machine, 960K is negligible.
> 2. Some extra physical memory for percpu kernel page table. 4K *
> (nr_cpus – 1) for PGD pages, plus the page tables used by percpu local
> mapping area. A couple of megabytes with Fedora default kernel config
> on AmpereOne with 160 cores.
> 3. Percpu allocation and free will be slower due to extra virtual
> memory allocation and page table manipulation. However, percpu is
> allocated by chunk. One chunk typically holds a lot percpu variables.
> So the slowdown should be negligible. The test result below also
> proved it.

It will also add a bit of TLB pressure as a lot of percpu allocations are
currently embedded in the linear address space backed by large page
mappings. Likely immaterial compared to the reduced overhead of
this_cpu_*().

One property that this breaks is per_cpu_ptr() of a given CPU disagreeing
with this_cpu_ptr(). e.g. If there are users that take this_cpu_ptr() and
uses that outside preempt disable block (which is a bit odd but allowed),
the end result would be surprising. Hmm... I wonder whether it'd be
worthwhile to keep this_cpu_ptr() returning the global address - ie. make it
access global offset from local mapping and then return the computed global
address. This should still be pretty cheap and gets rid of surprising and
potentially extremely subtle corner cases.

Generally sounds like a great solution for !x86.

Thanks.

-- 
tejun