Re: [PATCH 4/8] mm/slab: introduce kfree_rcu_nolock()

["Harry Yoo (Oracle)" <harry@kernel.org>]

On Wed, Apr 22, 2026 at 04:42:28PM +0200, Uladzislau Rezki wrote:
> On Thu, Apr 16, 2026 at 06:10:18PM +0900, Harry Yoo (Oracle) wrote:
> As discussed or noted earlier, having third argument and check the
> entire path with "if (allow_spin)" is not optimal and is not good
> approach. I do not think it this would be a good fit for mainline.

I understand that this pattern is pretty uncommon and adds complexity.
But there is a reason why we're doing this. As Alexei pointed out
earlier, even rare spikes of irq_work hurt performance [1]; that can be
avoided in most cases where the lock is not in use. That's why buddy [2]
and slab [3] accepted this pattern despite the added complexity?

[1] https://lore.kernel.org/linux-mm/CAADnVQKk_Bgi0bc-td_3pVpHYXR3CpC3R8rg-NHwdLEDiQSeNg@mail.gmail.com
[2] https://lore.kernel.org/linux-mm/20250222024427.30294-1-alexei.starovoitov@gmail.com 
[3] https://lore.kernel.org/linux-mm/20250909010007.1660-1-alexei.starovoitov@gmail.com

> I think a better option is to add a separate kvfree_rcu_nmi() helper,
> or similar, and avoid complicating the generic implementation. Otherwise,
> the common path risks becoming harder to maintain.

It's unfortunate that I didn't provide performance data to justify
adding complexity. I can try, but apparently you're not talking
about that.

Rather, you seem to be arguing that you're against this pattern
no matter what the benefits are?

I'm confused.

-- 
Cheers,
Harry / Hyeonggon