On 2/20/25 15:24, Keith Busch wrote:
On Thu, Feb 20, 2025 at 11:08:25AM +0000, Pavel Begunkov wrote:
On 2/18/25 22:42, Keith Busch wrote:
From: Keith Busch <kbusch@xxxxxxxxxx>
Frequent alloc/free cycles on these is pretty costly. Use an io cache to
more efficiently reuse these buffers.
Signed-off-by: Keith Busch <kbusch@xxxxxxxxxx>
---
include/linux/io_uring_types.h | 18 ++---
io_uring/filetable.c | 2 +-
io_uring/rsrc.c | 120 +++++++++++++++++++++++++--------
io_uring/rsrc.h | 2 +-
4 files changed, 104 insertions(+), 38 deletions(-)
diff --git a/include/linux/io_uring_types.h b/include/linux/io_uring_types.h
index 810d1dccd27b1..bbfb651506522 100644
--- a/include/linux/io_uring_types.h
+++ b/include/linux/io_uring_types.h
@@ -69,8 +69,18 @@ struct io_file_table {
unsigned int alloc_hint;
...
-struct io_rsrc_node *io_rsrc_node_alloc(int type)
+struct io_rsrc_node *io_rsrc_node_alloc(struct io_ring_ctx *ctx, int type)
{
struct io_rsrc_node *node;
- node = kzalloc(sizeof(*node), GFP_KERNEL);
+ if (type == IORING_RSRC_FILE)
+ node = kmalloc(sizeof(*node), GFP_KERNEL);
+ else
+ node = io_cache_alloc(&ctx->buf_table.node_cache, GFP_KERNEL);
That's why node allocators shouldn't be a part of the buffer table.
Are you saying you want file nodes to also subscribe to the cache? The
Yes, but it might be easier for you to focus on finalising the essential
parts, and then we can improve later.
two tables can be resized independently of each other, we don't know how
many elements the cache needs to hold.
I wouldn't try to correlate table sizes with desired cache sizes,
users can have quite different patterns like allocating a barely used
huge table. And you care about the speed of node change, which at
extremes is rather limited by CPU and performance and not spatiality
of the table. And you can also reallocate it as well.
--
Pavel Begunkov
