From: Gabriel Krisman Bertazi <krisman@suse.de>
To: axboe@kernel.dk
Cc: io-uring@vger.kernel.org
Subject: Re: [PATCH] io_uring: Use slab for struct io_buffer objects
Date: Thu, 07 Sep 2023 14:39:10 -0400 [thread overview]
Message-ID: <87sf7pakvl.fsf@suse.de> (raw)
In-Reply-To: <20230830003634.31568-1-krisman@suse.de> (Gabriel Krisman Bertazi's message of "Tue, 29 Aug 2023 20:36:34 -0400")
Gabriel Krisman Bertazi <krisman@suse.de> writes:
> The allocation of struct io_buffer for metadata of provided buffers is
> done through a custom allocator that directly gets pages and
> fragments them. But, slab would do just fine, as this is not a hot path
> (in fact, it is a deprecated feature) and, by keeping a custom allocator
> implementation we lose benefits like tracking, poisoning,
> sanitizers. Finally, the custom code is more complex and requires
> keeping the list of pages in struct ctx for no good reason. This patch
> cleans this path up and just uses slab.
>
> I microbenchmarked it by forcing the allocation of a large number of
> objects with the least number of io_uring commands possible (keeping
> nbufs=USHRT_MAX), with and without the patch. There is a slight
> increase in time spent in the allocation with slab, of course, but even
> when allocating to system resources exhaustion, which is not very
> realistic and happened around 1/2 billion provided buffers for me, it
> wasn't a significant hit in system time. Specially if we think of a
> real-world scenario, an application doing register/unregister of
> provided buffers will hit ctx->io_buffers_cache more often than actually
> going to slab.
>
> Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de>
Hi Jens,
Any feedback on this?
--
Gabriel Krisman Bertazi
next prev parent reply other threads:[~2023-09-07 18:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-30 0:36 [PATCH] io_uring: Use slab for struct io_buffer objects Gabriel Krisman Bertazi
2023-09-07 18:39 ` Gabriel Krisman Bertazi [this message]
2023-09-07 18:55 ` Jeff Moyer
2023-09-08 1:30 ` 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=87sf7pakvl.fsf@suse.de \
--to=krisman@suse.de \
--cc=axboe@kernel.dk \
--cc=io-uring@vger.kernel.org \
/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.