Re: [PATCH v2 13/20] arm64: percpu: Add infrastructure for preemptible this_cpu_*() ops

["David Hildenbrand (Arm)" <david@kernel.org>]

On 8/5/26 08:45, David Hildenbrand (Arm) wrote:
>> Atop v7.2-rc4, with GCC 15.2.0 and defconfig, this is compiled as:
>>
>> | <outline_this_cpu_add_u64>:
>> |        paciasp
>> |        stp     x29, x30, [sp, #-16]!
>> |        mrs     x2, sp_el0
>> |        mov     x29, sp
>> |        ldr     w3, [x2, #8]
>> |        add     w3, w3, #0x1
>> |        str     w3, [x2, #8]
>> |        mrs     x3, tpidr_el1
>> |        add     x0, x0, x3
>> | 1:     ldxr    x5, [x0]
>> |        add     x5, x5, x1
>> |        stxr    w4, x5, [x0]
>> |        cbnz    w4, 1b
>> |        ldr     x0, [x2, #8]
>> |        sub     x0, x0, #0x1
>> |        str     w0, [x2, #8]
>> |        cbz     x0, 2f
>> |        ldr     x0, [x2, #8]
>> |        cbnz    x0, 3f
>> | 2:     bl      preempt_schedule_notrace
>> | 3:     ldp     x29, x30, [sp], #16
>> |        autiasp
>> |        ret
> 
> FWIW, in a recent discussion on some prototype hacking [1] we saw some overhead
> in micro-benchmarks that would really hammer on a path that would now do a
> preempt_disable()+preempt_enable().
> 
> Switching from preempt_disable() to preempt_enable_no_resched() made it turn to
> noise. Of course, that has other undesirable impacts, and I am not sure if we
> are in the territory of code layout changes affecting the numbers.
> 
> Just mentioning it as some data point.
> 

[1] https://lore.kernel.org/linux-mm/20260630174852-mutt-send-email-mst@kernel.org/

-- 
Cheers,

David