From: Gabriel Krisman Bertazi <[email protected]>
To: [email protected], [email protected]
Cc: [email protected], Gabriel Krisman Bertazi <[email protected]>
Subject: [PATCH 0/9] Clean up alloc_cache allocations
Date: Mon, 18 Nov 2024 20:22:15 -0500 [thread overview]
Message-ID: <[email protected]> (raw)
Jens, Pavel,
The allocation paths that use alloc_cache duplicate the same code
pattern, sometimes in a quite convoluted way. This series cleans up
that code by folding the allocation into the cache code itself, making
it just an allocator function, and keeping the cache policy invisible to
callers. A bigger justification for doing this, beyond code simplicity,
is that it makes it trivial to test the impact of disabling the cache
and using slab directly, which I've used for slab improvement
experiments. I think this is one step forward in the direction
eventually lifting the alloc_cache into a proper magazine layer in slab
out of io_uring.
It survived liburing testsuite, and when microbenchmarking the
read-write path with mmtests and fio, I didn't observe any significant
performance variation (there was actually a 2% gain, but that was
within the variance of the test runs, making it not signficant and
surely test noise).
I'm specifically interested, and happy to do so, if there are specific
benchmarks you'd like me to run it against.
Thanks,
Gabriel Krisman Bertazi (9):
io_uring: Fold allocation into alloc_cache helper
io_uring: Add generic helper to allocate async data
io_uring/futex: Allocate ifd with generic alloc_cache helper
io_uring/poll: Allocate apoll with generic alloc_cache helper
io_uring/uring_cmd: Allocate async data through generic helper
io_uring/net: Allocate msghdr async data through helper
io_uring/rw: Allocate async data through helper
io_uring: Move old async data allocation helper to header
io_uring/msg_ring: Drop custom destructor
io_uring/alloc_cache.h | 7 +++++++
io_uring/futex.c | 13 +------------
io_uring/io_uring.c | 17 ++---------------
io_uring/io_uring.h | 22 ++++++++++++++++++++++
io_uring/msg_ring.c | 7 -------
io_uring/msg_ring.h | 1 -
io_uring/net.c | 28 ++++++++++------------------
io_uring/poll.c | 13 +++++--------
io_uring/rw.c | 28 ++++++++--------------------
io_uring/timeout.c | 5 ++---
io_uring/uring_cmd.c | 20 ++------------------
io_uring/waitid.c | 4 ++--
12 files changed, 61 insertions(+), 104 deletions(-)
--
2.47.0
next reply other threads:[~2024-11-19 1:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-19 1:22 Gabriel Krisman Bertazi [this message]
2024-11-19 1:22 ` [PATCH 1/9] io_uring: Fold allocation into alloc_cache helper Gabriel Krisman Bertazi
2024-11-19 2:02 ` Jens Axboe
2024-11-19 15:30 ` Gabriel Krisman Bertazi
2024-11-19 16:18 ` Jens Axboe
2024-11-19 1:22 ` [PATCH 2/9] io_uring: Add generic helper to allocate async data Gabriel Krisman Bertazi
2024-11-19 1:22 ` [PATCH 3/9] io_uring/futex: Allocate ifd with generic alloc_cache helper Gabriel Krisman Bertazi
2024-11-19 1:22 ` [PATCH 4/9] io_uring/poll: Allocate apoll " Gabriel Krisman Bertazi
2024-11-19 1:22 ` [PATCH 5/9] io_uring/uring_cmd: Allocate async data through generic helper Gabriel Krisman Bertazi
2024-11-19 1:22 ` [PATCH 6/9] io_uring/net: Allocate msghdr async data through helper Gabriel Krisman Bertazi
2024-11-19 1:22 ` [PATCH 7/9] io_uring/rw: Allocate " Gabriel Krisman Bertazi
2024-11-19 1:22 ` [PATCH 8/9] io_uring: Move old async data allocation helper to header Gabriel Krisman Bertazi
2024-11-19 1:22 ` [PATCH 9/9] io_uring/msg_ring: Drop custom destructor Gabriel Krisman Bertazi
2024-11-19 2:05 ` [PATCH 0/9] Clean up alloc_cache allocations Jens Axboe
2024-11-19 15:31 ` 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 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox