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

[David Hildenbrand (Arm)]

On 8/6/26 13:21, Mark Rutland wrote:
> On Wed, Aug 05, 2026 at 08:47:08AM +0200, David Hildenbrand (Arm) wrote:
>> On 8/5/26 08:45, David Hildenbrand (Arm) wrote:
>>>
>>> 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/
> 
> Thanks for the pointer.
> 
> IIUC in those cases you're using preempt_disable() .. preempt_enable()
> directly, not this_cpu_*(), right?

It was purely preempt_disable/preempt_enable experiments without any percpu stuff.

> 
> If so, patches 5 and 6 of this series [2,3] might have an impact, but I
> wouldn't expect a significant change unless you're calling
> preempt_enable a lot.
> 
> Please beware that it's not safe to use preempt_enable_no_resched()
> UNLESS it is immediately followed by a call to schedule(). That's not
> documented today (and I couldn't find a good reference), so more folk
> are likely to be tempted to use it...
Yes, that's also why we abandoned that (including for various other reasons :) ).

preempt_enable_no_resched() helped to identify that the preempt_enable() was
really causing the noticeable overhead, not the other minor stuff we added on
some hot paths.

-- 
Cheers,

David