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

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

On Thu, Apr 23, 2026 at 10:08:49AM +0900, Harry Yoo (Oracle) wrote:
> 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?

Perhaps we can avoid complicating existing kvfree_rcu batching
(and still avoid hurting performance).

Given that kfree_rcu_nolock() (at least BPF) doesn't need to free
vmalloc objects, we can make kfree_rcu_sheaf() handle most of frees
(slab already knows how to handle allow_spin = false) and fall back to
a simple irq_work as Ulad suggested.

But then we need to make kfree_rcu_sheaf() try harder (currently it
gives up when it fails to get an empty sheaf from the barn).

And I guess the tricky part is making kfree_rcu_sheaf() work on RT ;)

-- 
Cheers,
Harry / Hyeonggon