On Mon, Sep 20, 2021 at 02:02:19PM +0200, Vlastimil Babka wrote:

On 9/20/21 13:55, Hyeonggon Yoo wrote:

quoted

On Mon, Sep 20, 2021 at 11:07:36AM +0200, Vlastimil Babka wrote:

quoted

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@gmail.com/T/#u (local)

quoted

quoted

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.

quoted

quoted

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@linux.com/T/#u (local)