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

[Hyeonggon Yoo]

On Mon, Sep 20, 2021 at 02:02:19PM +0200, Vlastimil Babka wrote:
> 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.

Okay! I sent RFC v2. please check if how does look like to you:
	https://lore.kernel.org/linux-mm/20210920154816.31832-1-42.hyeyoo@xxxxxxxxx/T/#u

> >> 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" ?
>

added kmem_cache_alloc_cached, kmem_cache_free_cached in v2.

Thanks for your opinion Vlastimil,
Hyeonggon.

> >> 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
> >