Re: [PATCH] mm/slab: disallow kfree_rcu_sheaf() on PREEMPT_RT again

[Sebastian Andrzej Siewior]

On 2026-09-02 16:13:30 [+0200], Vlastimil Babka (SUSE) wrote:
> >> Per sashiko review it's actually bad too under the pi_lock, because
> >> GFP_NOWAIT means __GFP_KSWAPD_RECLAIM which can mean wakeup_kswapd() and
> >> thus also need scheduler locks. And it's not a PREEMPT_RT-only issue...
> > 
> > \o/
> 
> More like /o\

Yes, true. But it is not longer an RT-only issue.

> >> > It could have a pool of X
> >> > and if it runs out, it runs out and waits until the clean up process
> >> > feeds the used sheafs back. There is fallback and the run out is not the
> >> > usual case.
> >> 
> >> I'd rather not invent new pools, since there's fallback and the sheaf+barn
> >> is already a pool. Could be enough to make sure the allocation attempt is
> >> safe, i.e. use only __GFP_NOWARN.
> > 
> > So we avoid the allocation and just add it to the sheaf+barn and this is
> > it?
> 
> We don't need to avoid the allocation attempt if it's done in a safe way?

If it safe and does not not increase the free-latency too much then it
is fine.
Now that I look at the kvfree_call_rcu(), there a timer, hrtimer,
workqueue… Oh. And a __get_free_page().

> Note the new sheaf can be also served from its kmalloc slab almost
> immediately, going all the way to page allocator should be very rare.
> But if we stopped doing that sheaf allocation attemps completely, we could
> easily end up having long bursts of all kfree_rcu() being deferred.

Sure. If you have memory around then there is nothing wrong with using
it. In my naive thinking I assumed it should be enough to fill the
buffers and in times of bursts having plenty of RCU callbacks which are
throttled.

Sebastian