From 8c07f3e039978da18f6b8c173048fac28dd955ff Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sun, 16 Jul 2023 20:23:43 +0200 Subject: [PATCH] 6.1-stable patches added patches: io_uring-use-io_schedule-in-cqring-wait.patch --- ...uring-use-io_schedule-in-cqring-wait.patch | 79 +++++++++++++++++++ queue-6.1/series | 1 + 2 files changed, 80 insertions(+) create mode 100644 queue-6.1/io_uring-use-io_schedule-in-cqring-wait.patch diff --git a/queue-6.1/io_uring-use-io_schedule-in-cqring-wait.patch b/queue-6.1/io_uring-use-io_schedule-in-cqring-wait.patch new file mode 100644 index 00000000000..8c24c5b324d --- /dev/null +++ b/queue-6.1/io_uring-use-io_schedule-in-cqring-wait.patch @@ -0,0 +1,79 @@ +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 | 15 ++++++++++++--- + 1 file changed, 12 insertions(+), 3 deletions(-) + +--- a/io_uring/io_uring.c ++++ b/io_uring/io_uring.c +@@ -2346,7 +2346,7 @@ static inline int io_cqring_wait_schedul + struct io_wait_queue *iowq, + ktime_t *timeout) + { +- int ret; ++ int token, ret; + unsigned long check_cq; + + /* make sure we run task_work before checking for signals */ +@@ -2362,9 +2362,18 @@ static inline int io_cqring_wait_schedul + if (check_cq & BIT(IO_CHECK_CQ_DROPPED_BIT)) + return -EBADR; + } ++ ++ /* ++ * 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-6.1/series b/queue-6.1/series index d6c25090653..46debd1e222 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -583,3 +583,4 @@ blk-cgroup-reinit-blkg_iostat_set-after-clearing-in-blkcg_reset_stats.patch blk-cgroup-flush-stats-before-releasing-blkcg_gq.patch mips-dts-ci20-raise-vddcore-voltage-to-1.125-volts.patch block-make-sure-local-irq-is-disabled-when-calling-__blkcg_rstat_flush.patch +io_uring-use-io_schedule-in-cqring-wait.patch -- 2.47.3