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