Re: kmalloc_nolock() follow-ups, including kfree_rcu_nolock()

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

On 5/14/26 12:09, Harry Yoo (Oracle) wrote:
> On Thu, May 14, 2026 at 11:39:50AM +0200, Vlastimil Babka (SUSE) wrote:
>> There's still the fallback to the larger bucket, right?
>> That pretty much guarantees that if we fail due to a local lock in one
>> bucket (due to preempting its holder), a local lock in another bucket won't
>> be locked at the same time.
> 
> Right.
> 
>> However if local sheaves are exhausted, we might need a shared lock (barn,
>> list_lock, slab bit lock when no double cmpxchg) and that might be held by
>> another cpu in both buckets. But should be very rare.
> 
> I'm not sure what makes trylock failure on a list_lock rare?

That we can retry on different bucket. But maybe reality is different than
my hopes.

> When the local sheaves are exhausted, we're relying on either:
> 
> 1) another kmalloc or buddy user on that CPU (w/ allow_spin = true)
>    refills the local sheaves or PCP 
> 
> 2) trylock on list_lock or zone->lock succeeds
> 
> Without async refills unlike the BPF memory allocator.

Maybe we'll need those for sheaves at some point? Hope not.