Re: [PATCH v3 0/9] s390: Improve this_cpu operations

From: Yang Shi

Date: Thu May 21 2026 - 14:23:25 EST



On 5/21/26 3:17 AM, David Laight wrote:
On Wed, 20 May 2026 17:23:37 -0700
Yang Shi <yang@xxxxxxxxxxxxxxxxxxxxxx> wrote:

On 5/20/26 3:34 PM, David Laight wrote:
...
But I'm sure I remember that some cpu don't like having the same
physical address at different virtual addresses (and not just those
with VIVT caches like some sparc cpu).
Yeah, VIVT cache doesn't like it due to cache alias. But the mapping is
really percpu, so the mapping to the physical address belonging to
another CPU should never pollute the current CPU's cache if I don't miss
something.

I'm sure code can end up accessing the current cpu's percpu data
using the same address that other cpu use - there are definitely
places where it needs that address.
No, it is not. In the percpu page table approach, we use different
address for this_cpu_*() and per_cpu_ptr() which is mainly used to
initialize percpu data for all CPUs.
You missed something.

Look, for example, at kernel/locking/osq_lock.c
The code uses this_cpu_ptr() and then both dereferences the pointer
and writes it to places that other cpu will use.
It also uses per_cpu_ptr() to get an address it can use for the per-cpu
data of another cpu.
(That code all assumes preemption is disabled.)

this_cpu_ptr() uses different addresses for different CPUs. It is a special case, it is not due to VIVT, but because it may confuse list API. Because list API determines list is empty by comparing pointers (head->next == head). this_cpu_read/write/add/sub, etc, are fine.

And per_cpu_ptr() also uses different addresses for different CPUs.

The lwn article explained it. https://lwn.net/SubscriberLink/1073395/12c08f128e515809/

Thanks,
Yang


-- David

Thanks,
Yang