Re: [RFC PATCH] Introducing lockless cache built on top of slab allocator

[Vlastimil Babka]

On 9/20/21 13:55, Hyeonggon Yoo wrote:
> On Mon, Sep 20, 2021 at 11:07:36AM +0200, Vlastimil Babka wrote:
>> I guess making it opt-in only for caches where performance improvement was
>> measured would make it easier to add, as for some caches it would mean no
>> improvement, but increased memory usage. But of course it makes the API more
>> harder to use.
> 
> Do you mean "lockless cache" it should be separate from slab because some caches
> doesn't benefit at all?

I meant it seems to be a valid approach to have a special kmem_cache flag
and allocation function variants, as you discussed. That covers the "some
caches don't benefit at all" while being an integral part of the allocator,
so others don't have to build ad-hoc solutions on top of it, and possibly it
can be also more optimized given access to the SLUB internals.

>> I'd be careful about the name "lockless", as that's ambiguous. Is it "mostly
>> lockless" therefore fast, but if the cache is empty, it will still take
>> locks as part of refill?
> 
> It is actually "mostly lockless" so it is ambiguous.
> Can you suggest a name? like try_lockless or anything?

"cached" instead of "lockless" ?

>> Or is it lockless always, therefore useful in
>> contexts that can take no locks, but then the caller has to have fallbacks
>> in case the cache is empty and nothing is allocated?
>> 
>> [1] https://lore.kernel.org/linux-mm/20100804024531.914852850@xxxxxxxxx/T/#u
>