From: Pavel Begunkov <[email protected]>
To: Jens Axboe <[email protected]>, [email protected]
Subject: [PATCH 16/16] io_uring: optimise io_req_task_work_add()
Date: Fri, 19 Mar 2021 17:22:44 +0000 [thread overview]
Message-ID: <23fda3980a56cec26385a81030a6cc9e01c04bf6.1616167719.git.asml.silence@gmail.com> (raw)
In-Reply-To: <[email protected]>
Inline io_task_work_add() into io_req_task_work_add(). They both work
with a request, so keeping them separate doesn't make things much more
clear, but merging allows optimise it. Apart from small wins like not
reading req->ctx or not calculating @notify in the hot path, i.e. with
tctx->task_state set, it avoids doing wake_up_process() for every single
add, but only after actually done task_work_add().
Signed-off-by: Pavel Begunkov <[email protected]>
---
fs/io_uring.c | 50 ++++++++++++++++++--------------------------------
1 file changed, 18 insertions(+), 32 deletions(-)
diff --git a/fs/io_uring.c b/fs/io_uring.c
index d7b4cbe2ac3a..3548b2e60ba5 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -1931,13 +1931,17 @@ static void tctx_task_work(struct callback_head *cb)
cond_resched();
}
-static int io_task_work_add(struct task_struct *tsk, struct io_kiocb *req,
- enum task_work_notify_mode notify)
+static int io_req_task_work_add(struct io_kiocb *req)
{
+ struct task_struct *tsk = req->task;
struct io_uring_task *tctx = tsk->io_uring;
+ enum task_work_notify_mode notify;
struct io_wq_work_node *node, *prev;
unsigned long flags;
- int ret;
+ int ret = 0;
+
+ if (unlikely(tsk->flags & PF_EXITING))
+ return -ESRCH;
WARN_ON_ONCE(!tctx);
@@ -1950,14 +1954,23 @@ static int io_task_work_add(struct task_struct *tsk, struct io_kiocb *req,
test_and_set_bit(0, &tctx->task_state))
return 0;
- if (!task_work_add(tsk, &tctx->task_work, notify))
+ /*
+ * SQPOLL kernel thread doesn't need notification, just a wakeup. For
+ * all other cases, use TWA_SIGNAL unconditionally to ensure we're
+ * processing task_work. There's no reliable way to tell if TWA_RESUME
+ * will do the job.
+ */
+ notify = (req->ctx->flags & IORING_SETUP_SQPOLL) ? TWA_NONE : TWA_SIGNAL;
+
+ if (!task_work_add(tsk, &tctx->task_work, notify)) {
+ wake_up_process(tsk);
return 0;
+ }
/*
* Slow path - we failed, find and delete work. if the work is not
* in the list, it got run and we're fine.
*/
- ret = 0;
spin_lock_irqsave(&tctx->task_lock, flags);
wq_list_for_each(node, prev, &tctx->task_list) {
if (&req->io_task_work.node == node) {
@@ -1971,33 +1984,6 @@ static int io_task_work_add(struct task_struct *tsk, struct io_kiocb *req,
return ret;
}
-static int io_req_task_work_add(struct io_kiocb *req)
-{
- struct task_struct *tsk = req->task;
- struct io_ring_ctx *ctx = req->ctx;
- enum task_work_notify_mode notify;
- int ret;
-
- if (tsk->flags & PF_EXITING)
- return -ESRCH;
-
- /*
- * SQPOLL kernel thread doesn't need notification, just a wakeup. For
- * all other cases, use TWA_SIGNAL unconditionally to ensure we're
- * processing task_work. There's no reliable way to tell if TWA_RESUME
- * will do the job.
- */
- notify = TWA_NONE;
- if (!(ctx->flags & IORING_SETUP_SQPOLL))
- notify = TWA_SIGNAL;
-
- ret = io_task_work_add(tsk, req, notify);
- if (!ret)
- wake_up_process(tsk);
-
- return ret;
-}
-
static bool io_run_task_work_head(struct callback_head **work_head)
{
struct callback_head *work, *next;
--
2.24.0
next prev parent reply other threads:[~2021-03-19 17:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-19 17:22 [PATCH 00/16] random 5.13 bits Pavel Begunkov
2021-03-19 17:22 ` [PATCH 01/16] io_uring: don't take ctx refs in task_work handler Pavel Begunkov
2021-03-19 17:22 ` [PATCH 02/16] io_uring: optimise io_uring_enter() Pavel Begunkov
2021-03-19 17:22 ` [PATCH 03/16] io_uring: optimise tctx node checks/alloc Pavel Begunkov
2021-03-19 17:22 ` [PATCH 04/16] io_uring: keep io_req_free_batch() call locality Pavel Begunkov
2021-03-19 17:22 ` [PATCH 05/16] io_uring: inline __io_queue_linked_timeout() Pavel Begunkov
2021-03-19 17:22 ` [PATCH 06/16] io_uring: optimise success case of __io_queue_sqe Pavel Begunkov
2021-03-19 17:22 ` [PATCH 07/16] io_uring: refactor io_flush_cached_reqs() Pavel Begunkov
2021-03-19 17:22 ` [PATCH 08/16] io_uring: refactor rsrc refnode allocation Pavel Begunkov
2021-03-19 17:22 ` [PATCH 09/16] io_uring: inline io_put_req and friends Pavel Begunkov
2021-03-19 17:22 ` [PATCH 10/16] io_uring: refactor io_free_req_deferred() Pavel Begunkov
2021-03-19 17:22 ` [PATCH 11/16] io_uring: add helper flushing locked_free_list Pavel Begunkov
2021-03-19 17:22 ` [PATCH 12/16] io_uring: remove __io_req_task_cancel() Pavel Begunkov
2021-03-19 17:22 ` [PATCH 13/16] io_uring: inline io_clean_op()'s fast path Pavel Begunkov
2021-03-19 17:22 ` [PATCH 14/16] io_uring: optimise io_dismantle_req() " Pavel Begunkov
2021-03-19 17:22 ` [PATCH 15/16] io_uring: abolish old io_put_file() Pavel Begunkov
2021-03-19 17:22 ` Pavel Begunkov [this message]
2021-03-19 18:59 ` [PATCH 00/16] random 5.13 bits 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=23fda3980a56cec26385a81030a6cc9e01c04bf6.1616167719.git.asml.silence@gmail.com \
[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