From: Gabriel Krisman Bertazi <krisman@suse.de>
To: Uzair Beg <uzairbeg11@gmail.com>, io-uring@vger.kernel.org
Cc: axboe@kernel.dk, asml.silence@gmail.com,
Chengfeng Lin <lin2530632123@gmail.com>,
linux-kernel@vger.kernel.org, Uzair Beg <uzairbeg11@gmail.com>
Subject: Re: [RFC PATCH 1/3] io_uring/rsrc: allocate io_rsrc_node from a dedicated kmem_cache
Date: Tue, 15 Sep 2026 14:54:29 -0300 [thread overview]
Message-ID: <87jyom1ju2.fsf@mailhost.krisman.be> (raw)
In-Reply-To: <20260914092049.130079-2-uzairbeg11@gmail.com>
Uzair Beg <uzairbeg11@gmail.com> writes:
> io_rsrc_node allocations come from the generic kmalloc-32 bucket via
> io_cache_alloc_new(). On a first fill of a sparse fixed file table the
> per-ring node cache is empty by construction, since io_reset_rsrc_node()
> returns early on a NULL slot and nothing is freed back, so every install
> takes an allocator round trip.
>
> Add an optional kmem_cache to io_alloc_cache and use it for the node
> cache. The slab pointer defaults to NULL, so other io_alloc_cache users
> are unchanged and imu_cache keeps using kmalloc, its element size being
> variable. All three free paths honour the slab.
>
> On its own this is neutral on the reported workload. It exists so that
> the following patches can use kmem_cache_alloc_bulk(), which has no
> equivalent for plain kmalloc.
>
> Reported-by: Chengfeng Lin <lin2530632123@gmail.com>
> Closes: https://lore.kernel.org/io-uring/CANGjgdmt0FQ=offsdfn+wEaDxbOFoAa6bi92X_vEo4S6aCZ56A@mail.gmail.com/
> Tested-by: Chengfeng Lin <lin2530632123@gmail.com>
> Signed-off-by: Uzair Beg <uzairbeg11@gmail.com>
> ---
> include/linux/io_uring_types.h | 1 +
> io_uring/alloc_cache.c | 14 +++++++++++---
> io_uring/alloc_cache.h | 8 ++++++--
> io_uring/io_uring.c | 5 +++++
> io_uring/io_uring.h | 1 +
> io_uring/rsrc.c | 2 ++
> 6 files changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/io_uring_types.h b/include/linux/io_uring_types.h
> index c2ea6280901..e8d5a585a60 100644
> --- a/include/linux/io_uring_types.h
> +++ b/include/linux/io_uring_types.h
> @@ -253,6 +253,7 @@ struct io_alloc_cache {
> unsigned int max_cached;
> unsigned int elem_size;
> unsigned int init_clear;
> + struct kmem_cache *slab;
> };
Not opposed to having a slab, but I actually think it is
unnecessary. see patch 2. If we do that, we actually should delete the
async_size parameter in the opdef, since it is now redundant. But
see comments in patch 2.
>
> struct io_ring_ctx {
> diff --git a/io_uring/alloc_cache.c b/io_uring/alloc_cache.c
> index 58423888b73..a44b82a80f1 100644
> --- a/io_uring/alloc_cache.c
> +++ b/io_uring/alloc_cache.c
> @@ -10,8 +10,12 @@ void io_alloc_cache_free(struct io_alloc_cache *cache,
> if (!cache->entries)
> return;
>
> - while ((entry = io_alloc_cache_get(cache)) != NULL)
> - free(entry);
> + while ((entry = io_alloc_cache_get(cache)) != NULL) {
> + if (cache->slab)
> + kmem_cache_free(cache->slab, entry);
> + else
> + free(entry);
> + }
FWIW, this is exactly why we have the (*free) callback, you should have a function
for your specific type used as a callback that does the kmem_cache_free
so you don't need the if/else here.
But for a simple kmem_cache_free, kfree works just fine.
--
Gabriel Krisman Bertazi
next prev parent reply other threads:[~2026-09-15 17:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 9:20 [RFC PATCH 0/3] io_uring/rsrc: reduce node allocation cost on sparse file table installs Uzair Beg
2026-09-14 9:20 ` [RFC PATCH 1/3] io_uring/rsrc: allocate io_rsrc_node from a dedicated kmem_cache Uzair Beg
2026-09-15 17:54 ` Gabriel Krisman Bertazi [this message]
2026-09-25 16:36 ` Uzair Beg
2026-09-14 9:20 ` [RFC PATCH 2/3] io_uring/rsrc: bulk refill the node cache on allocation miss Uzair Beg
2026-09-14 9:20 ` [RFC PATCH 3/3] io_uring/rsrc: prefill the node cache when a file table is registered empty Uzair Beg
2026-09-15 18:20 ` Gabriel Krisman Bertazi
2026-09-25 16:39 ` Uzair Beg
2026-09-25 19:42 ` Gabriel Krisman Bertazi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87jyom1ju2.fsf@mailhost.krisman.be \
--to=krisman@suse.de \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=io-uring@vger.kernel.org \
--cc=lin2530632123@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=uzairbeg11@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.