From: "Pavel Begunkov (Silence)" <asml.silence@gmail.com>
To: Jens Axboe <axboe@kernel.dk>, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Pavel Begunkov <asml.silence@gmail.com>
Subject: [PATCH v2 2/2] io_uring: Optimise cq waiting with wait_threshold
Date: Sun, 22 Sep 2019 11:08:51 +0300 [thread overview]
Message-ID: <321aa8db2bbefb8f4b41d7b2608f629fbd5d3d55.1569139018.git.asml.silence@gmail.com> (raw)
In-Reply-To: <cover.1569139018.git.asml.silence@gmail.com>
From: Pavel Begunkov <asml.silence@gmail.com>
While waiting for completion events in io_cqring_wait(), the process
will be waken up inside wait_threshold_interruptible() on any request
completion, check num of events in completion queue and potentially go
to sleep again.
Apparently, there could be a lot of such spurious wakeups with lots of
overhead. It especially manifests itself, when min_events is large, and
completions are arriving one by one or in small batches (that usually
is true).
E.g. if device completes requests one by one and io_uring_enter is
waiting for 100 events, then there will be ~99 spurious wakeups.
Use new wait_threshold_*() instead, which won't wake it up until
necessary number of events is collected.
Performance test:
The first thread generates requests (QD=512) one by one, so they will
be completed in the similar pattern. The second thread waiting for
128 events to complete.
Tested with null_blk with 5us delay
and 3.8GHz Intel CPU.
throughput before: 270 KIOPS
throughput after: 370 KIOPS
~40% throughput boost, exaggerated, but makes a point.
v2: wake always in io_timeout_fn() with WQ_THRESHOLD_WAKE_ALWAYS
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
---
fs/io_uring.c | 35 ++++++++++++++++++++++++-----------
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/fs/io_uring.c b/fs/io_uring.c
index 5c3f2bb81637..05f4391c7bbe 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -70,6 +70,7 @@
#include <linux/nospec.h>
#include <linux/sizes.h>
#include <linux/hugetlb.h>
+#include <linux/wait_threshold.h>
#include <uapi/linux/io_uring.h>
@@ -414,6 +415,13 @@ static struct io_ring_ctx *io_ring_ctx_alloc(struct io_uring_params *p)
return ctx;
}
+static unsigned int io_cqring_events(struct io_rings *rings)
+{
+ /* See comment at the top of this file */
+ smp_rmb();
+ return READ_ONCE(rings->cq.tail) - READ_ONCE(rings->cq.head);
+}
+
static inline bool io_sequence_defer(struct io_ring_ctx *ctx,
struct io_kiocb *req)
{
@@ -559,16 +567,27 @@ static void io_cqring_fill_event(struct io_ring_ctx *ctx, u64 ki_user_data,
}
}
-static void io_cqring_ev_posted(struct io_ring_ctx *ctx)
+static void __io_cqring_ev_posted(struct io_ring_ctx *ctx,
+ unsigned int nr_events)
{
if (waitqueue_active(&ctx->wait))
- wake_up(&ctx->wait);
+ wake_up_threshold(&ctx->wait, nr_events);
if (waitqueue_active(&ctx->sqo_wait))
wake_up(&ctx->sqo_wait);
if (ctx->cq_ev_fd)
eventfd_signal(ctx->cq_ev_fd, 1);
}
+static inline void io_cqring_ev_posted(struct io_ring_ctx *ctx)
+{
+ __io_cqring_ev_posted(ctx, io_cqring_events(ctx->rings));
+}
+
+static inline void io_cqring_timeout_posted(struct io_ring_ctx *ctx)
+{
+ __io_cqring_ev_posted(ctx, WQ_THRESHOLD_WAKE_ALWAYS);
+}
+
static void io_cqring_add_event(struct io_ring_ctx *ctx, u64 user_data,
long res)
{
@@ -587,7 +606,7 @@ static void io_ring_drop_ctx_refs(struct io_ring_ctx *ctx, unsigned refs)
percpu_ref_put_many(&ctx->refs, refs);
if (waitqueue_active(&ctx->wait))
- wake_up(&ctx->wait);
+ wake_up_threshold(&ctx->wait, io_cqring_events(ctx->rings));
}
static struct io_kiocb *io_get_req(struct io_ring_ctx *ctx,
@@ -722,12 +741,6 @@ static void io_put_req(struct io_kiocb *req)
io_free_req(req);
}
-static unsigned io_cqring_events(struct io_rings *rings)
-{
- /* See comment at the top of this file */
- smp_rmb();
- return READ_ONCE(rings->cq.tail) - READ_ONCE(rings->cq.head);
-}
/*
* Find and free completed poll iocbs
@@ -1824,7 +1837,7 @@ static enum hrtimer_restart io_timeout_fn(struct hrtimer *timer)
io_commit_cqring(ctx);
spin_unlock_irqrestore(&ctx->completion_lock, flags);
- io_cqring_ev_posted(ctx);
+ io_cqring_timeout_posted(ctx);
io_put_req(req);
return HRTIMER_NORESTART;
@@ -2723,7 +2736,7 @@ static int io_cqring_wait(struct io_ring_ctx *ctx, int min_events,
* we started waiting. For timeouts, we always want to return to
* userspace.
*/
- ret = wait_event_interruptible(ctx->wait,
+ ret = wait_threshold_interruptible(ctx->wait, min_events,
io_cqring_events(rings) >= min_events ||
atomic_read(&ctx->cq_timeouts) != nr_timeouts);
restore_saved_sigmask_unless(ret == -ERESTARTSYS);
--
2.23.0
next prev parent reply other threads:[~2019-09-22 8:09 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-22 8:08 [PATCH v2 0/2] Optimise io_uring completion waiting Pavel Begunkov (Silence)
2019-09-22 8:08 ` [PATCH v2 1/2] sched/wait: Add wait_threshold Pavel Begunkov (Silence)
2019-09-23 7:19 ` Peter Zijlstra
2019-09-23 16:37 ` Pavel Begunkov
2019-09-23 19:27 ` Peter Zijlstra
2019-09-23 20:23 ` Peter Zijlstra
2019-09-24 6:44 ` Pavel Begunkov
2019-09-22 8:08 ` Pavel Begunkov (Silence) [this message]
2019-09-22 15:51 ` [PATCH v2 0/2] Optimise io_uring completion waiting Jens Axboe
2019-09-23 8:35 ` Ingo Molnar
2019-09-23 16:21 ` Pavel Begunkov
2019-09-23 16:32 ` Pavel Begunkov
2019-09-23 20:48 ` Jens Axboe
2019-09-23 23:00 ` Jens Axboe
2019-09-24 7:06 ` Pavel Begunkov
2019-09-24 8:02 ` Jens Axboe
2019-09-24 8:27 ` Jens Axboe
2019-09-24 8:36 ` Jens Axboe
2019-09-24 9:33 ` Pavel Begunkov
2019-09-24 10:11 ` Jens Axboe
2019-09-24 9:49 ` Peter Zijlstra
2019-09-24 10:13 ` Jens Axboe
2019-09-24 10:34 ` Jens Axboe
2019-09-24 11:11 ` Pavel Begunkov
2019-09-24 11:15 ` Jens Axboe
2019-09-24 11:23 ` Pavel Begunkov
2019-09-24 13:13 ` Jens Axboe
2019-09-24 17:33 ` Pavel Begunkov
2019-09-24 17:46 ` Jens Axboe
2019-09-24 18:28 ` Pavel Begunkov
2019-09-24 19:32 ` Jens Axboe
2019-09-24 11:43 ` Peter Zijlstra
2019-09-24 12:57 ` Jens Axboe
2019-09-24 11:33 ` Peter Zijlstra
2019-09-24 9:20 ` Pavel Begunkov
2019-09-24 10:09 ` Jens Axboe
2019-09-24 9:21 ` Pavel Begunkov
2019-09-24 10:09 ` Jens Axboe
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=321aa8db2bbefb8f4b41d7b2608f629fbd5d3d55.1569139018.git.asml.silence@gmail.com \
--to=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®