Re: [RFC RESEND v10 03/14] irq & spin_lock: Add counted interrupt disabling/enabling

[Joel Fernandes]

On 6/16/2025 2:02 PM, Boqun Feng wrote:
> On Mon, Jun 16, 2025 at 01:54:47PM -0400, Joel Fernandes wrote:
> [..]
>>>> Your SOB is placed wrong, should be below Boqun's. This way it gets
>>>> lost.
>>>>
>>>> Also, is there effort planned to fully remove the save/restore variant?
>>>> As before, my main objection is adding variants with overlapping
>>>> functionality while not cleaning up the pre-existing code.
>>>>
>>> My plan is to map local_irq_disable() to local_interrupt_disable() and
>>> keep local_irq_save() as it is. That is, local_irq_disable() is the
>>> auto-pilot version and local_irq_save/restore() is the manual version.
>>> The reason is that I can see more "creative" (i.e. unpaired) usage of
>>> local_irq_save/restore(), and maybe someone would like to keep them.
>>> Thoughts?
>> My thought is it is better to keep them separate at first, let
>> local_interrupt_disable() stabilize with a few users, then convert the
>> callers (possibly with deprecation warnings with checkpatch), and then remove
>> the old API.
>>
> No objection to doing it slowly 😉 My point was more about the plan is
> to replace local_irq_disable() with local_interrupt_disable() other than
> replacing local_irq_save() with local_interrupt_disable().

At first glance that makes sense. Was there some concern about overhead? Me and
Steve did some experiments back in the day where we found local_irq_disable()
can be performance-sensitive, but we were adding tracers/tracing which
presumably can be higher overhead than what this series is doing.

thanks,

 - Hiek