From 3e8cfdf53a4a58ea6ee14c779d4ecaf1f70a4bf5 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sun, 16 Jul 2023 20:23:25 +0200 Subject: [PATCH] 5.10-stable patches added patches: io_uring-use-io_schedule-in-cqring-wait.patch --- ...uring-use-io_schedule-in-cqring-wait.patch | 78 +++++++++++++++++++ queue-5.10/series | 1 + 2 files changed, 79 insertions(+) create mode 100644 queue-5.10/io_uring-use-io_schedule-in-cqring-wait.patch diff --git a/queue-5.10/io_uring-use-io_schedule-in-cqring-wait.patch b/queue-5.10/io_uring-use-io_schedule-in-cqring-wait.patch new file mode 100644 index 00000000000..147d8b6beb0 --- /dev/null +++ b/queue-5.10/io_uring-use-io_schedule-in-cqring-wait.patch @@ -0,0 +1,78 @@ +From 8a796565cec3601071cbbd27d6304e202019d014 Mon Sep 17 00:00:00 2001 +From: Andres Freund +Date: Fri, 7 Jul 2023 09:20:07 -0700 +Subject: io_uring: Use io_schedule* in cqring wait + +From: Andres Freund + +commit 8a796565cec3601071cbbd27d6304e202019d014 upstream. + +I observed poor performance of io_uring compared to synchronous IO. That +turns out to be caused by deeper CPU idle states entered with io_uring, +due to io_uring using plain schedule(), whereas synchronous IO uses +io_schedule(). + +The losses due to this are substantial. On my cascade lake workstation, +t/io_uring from the fio repository e.g. yields regressions between 20% +and 40% with the following command: +./t/io_uring -r 5 -X0 -d 1 -s 1 -c 1 -p 0 -S$use_sync -R 0 /mnt/t2/fio/write.0.0 + +This is repeatable with different filesystems, using raw block devices +and using different block devices. + +Use io_schedule_prepare() / io_schedule_finish() in +io_cqring_wait_schedule() to address the difference. + +After that using io_uring is on par or surpassing synchronous IO (using +registered files etc makes it reliably win, but arguably is a less fair +comparison). + +There are other calls to schedule() in io_uring/, but none immediately +jump out to be similarly situated, so I did not touch them. Similarly, +it's possible that mutex_lock_io() should be used, but it's not clear if +there are cases where that matters. + +Cc: stable@vger.kernel.org # 5.10+ +Cc: Pavel Begunkov +Cc: io-uring@vger.kernel.org +Cc: linux-kernel@vger.kernel.org +Signed-off-by: Andres Freund +Link: https://lore.kernel.org/r/20230707162007.194068-1-andres@anarazel.de +[axboe: minor style fixup] +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + io_uring/io_uring.c | 14 +++++++++++--- + 1 file changed, 11 insertions(+), 3 deletions(-) + +--- a/io_uring/io_uring.c ++++ b/io_uring/io_uring.c +@@ -7625,7 +7625,7 @@ static inline int io_cqring_wait_schedul + struct io_wait_queue *iowq, + ktime_t *timeout) + { +- int ret; ++ int token, ret; + + /* make sure we run task_work before checking for signals */ + ret = io_run_task_work_sig(); +@@ -7635,9 +7635,17 @@ static inline int io_cqring_wait_schedul + if (test_bit(0, &ctx->check_cq_overflow)) + return 1; + ++ /* ++ * Use io_schedule_prepare/finish, so cpufreq can take into account ++ * that the task is waiting for IO - turns out to be important for low ++ * QD IO. ++ */ ++ token = io_schedule_prepare(); ++ ret = 0; + if (!schedule_hrtimeout(timeout, HRTIMER_MODE_ABS)) +- return -ETIME; +- return 1; ++ ret = -ETIME; ++ io_schedule_finish(token); ++ return ret; + } + + /* diff --git a/queue-5.10/series b/queue-5.10/series index bb934adf9d5..6e2f36d521d 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -313,3 +313,4 @@ tpm-tpm_tis-claim-locality-in-interrupt-handler.patch selftests-bpf-add-verifier-test-for-ptr_to_mem-spill.patch block-add-overflow-checks-for-amiga-partition-support.patch mips-dts-ci20-raise-vddcore-voltage-to-1.125-volts.patch +io_uring-use-io_schedule-in-cqring-wait.patch -- 2.47.3