On Wed, Jul 28, 2021 at 11:46 AM Paul E. McKenney <paulmck@xxxxxxxxxx> wrote:
>
> But atomic_read_this_cpu(&rcu_data.dynticks) isn't all that much shorter
> than atomic_read(this_cpu_ptr(&rcu_data.dynticks)).
It's not so much that it's shorter to write for a human, it's that we
could generate better code for it.
That atomic_read(this_cpu_ptr()) pattern generates code like
movq $rcu_data+288, %rax
add %gs:this_cpu_off(%rip), %rax
movl (%rax), %eax
but it *could* just generate
movl %gs:rcu_data+288, %rax
instead.
Similar patterns for the other per-cpu atomics, ie it would be
possible to just generate
lock ; xaddl %gs:..., %rax
instead of generating the address by doing that "add %gs:this_cpu_off" thing..
But no, it doesn't look like there are enough users of this to matter.
We're just talking a few extra bytes, and a couple of extra
instructions (and possibly slightly higher register pressure, which
then generates more instructions).
The *expensive* part remains the SMP serialization of the "lock".
Linus
