From: Jens Axboe <[email protected]>
To: "Darrick J . Wong" <[email protected]>
Cc: io-uring <[email protected]>,
"[email protected]" <[email protected]>
Subject: [GIT PULL] Improve iomap async dio performance
Date: Fri, 21 Jul 2023 10:54:41 -0600 [thread overview]
Message-ID: <[email protected]> (raw)
Hi,
Here's the pull request for improving async dio performance with
iomap. Contains a few generic cleanups as well, but the meat of it
is described in the tagged commit message below.
Please pull for 6.6!
The following changes since commit ccff6d117d8dc8d8d86e8695a75e5f8b01e573bf:
Merge tag 'perf-tools-fixes-for-v6.5-1-2023-07-18' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools (2023-07-18 14:51:29 -0700)
are available in the Git repository at:
git://git.kernel.dk/linux.git tags/xfs-async-dio
for you to fetch changes up to 901a0c0e4248aa7e3ab4dce9a8c67c47215e6ccc:
iomap: use an unsigned type for IOMAP_DIO_* defines (2023-07-21 10:34:42 -0600)
----------------------------------------------------------------
iomap always punts async dio write completions to a workqueue, which has
a cost in terms of efficiency (now you need an unrelated worker to
process it) and latency (now you're bouncing a completion through an
async worker, which is a classic slowdown scenario).
Even for writes that should, in theory, be able to complete inline, if
we race with truncate or need to invalidate pages post completion, we
cannot sanely be in IRQ context as the locking types don't allow for
that.
io_uring handles IRQ completions via task_work, and for writes that
don't need to do extra IO at completion time, we can safely complete
them inline from that. This patchset adds IOCB_DIO_CALLER_COMP, which an
IO issuer can set to inform the completion side that any extra work that
needs doing for that completion can be punted to a safe task context.
The iomap dio completion will happen in hard/soft irq context, and we
need a saner context to process these completions. IOCB_DIO_CALLER_COMP
is added, which can be set in a struct kiocb->ki_flags by the issuer. If
the completion side of the iocb handling understands this flag, it can
choose to set a kiocb->dio_complete() handler and just call ki_complete
from IRQ context. The issuer must then ensure that this callback is
processed from a task. io_uring punts IRQ completions to task_work
already, so it's trivial wire it up to run more of the completion before
posting a CQE. This is good for up to a 37% improvement in
throughput/latency for low queue depth IO, patch 5 has the details.
If we need to do real work at completion time, iomap will clear the
IOMAP_DIO_CALLER_COMP flag.
This work came about when Andres tested low queue depth dio writes for
postgres and compared it to doing sync dio writes, showing that the
async processing slows us down a lot.
----------------------------------------------------------------
Jens Axboe (9):
iomap: cleanup up iomap_dio_bio_end_io()
iomap: add IOMAP_DIO_INLINE_COMP
iomap: treat a write through cache the same as FUA
iomap: completed polled IO inline
iomap: only set iocb->private for polled bio
fs: add IOCB flags related to passing back dio completions
io_uring/rw: add write support for IOCB_DIO_CALLER_COMP
iomap: support IOCB_DIO_CALLER_COMP
iomap: use an unsigned type for IOMAP_DIO_* defines
fs/iomap/direct-io.c | 166 +++++++++++++++++++++++++++++++++++++++------------
include/linux/fs.h | 35 ++++++++++-
io_uring/rw.c | 26 +++++++-
3 files changed, 183 insertions(+), 44 deletions(-)
--
Jens Axboe
next reply other threads:[~2023-07-21 16:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-21 16:54 Jens Axboe [this message]
2023-07-21 22:08 ` [GIT PULL] Improve iomap async dio performance Dave Chinner
2023-07-22 1:02 ` Darrick J. Wong
2023-07-22 2:53 ` 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 \
[email protected] \
[email protected] \
[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