From: Jens Axboe <[email protected]>
To: [email protected]
Cc: [email protected], [email protected],
[email protected]
Subject: [PATCHSET RFC 0/11] Add support for async buffered reads
Date: Fri, 22 May 2020 14:23:00 -0600 [thread overview]
Message-ID: <[email protected]> (raw)
We technically support this already through io_uring, but it's
implemented with a thread backend to support cases where we would
block. This isn't ideal.
After a few prep patches, the core of this patchset is adding support
for async callbacks on page unlock. With this primitive, we can simply
retry the IO operation. With io_uring, this works a lot like poll based
retry for files that support it. If a page is currently locked and
needed, -EIOCBQUEUED is returned with a callback armed. The callers
callback is responsible for restarting the operation.
With this callback primitive, we can add support for
generic_file_buffered_read(), which is what most file systems end up
using for buffered reads. XFS/ext4/btrfs/bdev is wired up, but probably
trivial to add more.
The file flags support for this by setting FMODE_BUF_RASYNC, similar
to what we do for FMODE_NOWAIT. Open to suggestions here if this is
the preferred method or not.
In terms of results, I wrote a small test app that randomly reads 4G
of data in 4K chunks from a file hosted by ext4. The app uses a queue
depth of 32.
preadv for comparison:
real 1m13.821s
user 0m0.558s
sys 0m11.125s
CPU ~13%
Mainline:
real 0m12.054s
user 0m0.111s
sys 0m5.659s
CPU ~32% + ~50% == ~82%
This patchset:
real 0m9.283s
user 0m0.147s
sys 0m4.619s
CPU ~52%
The CPU numbers are just a rough estimate. For the mainline io_uring
run, this includes the app itself and all the threads doing IO on its
behalf (32% for the app, ~1.6% per worker and 32 of them). Context
switch rate is much smaller with the patchset, since we only have the
one task performing IO.
The goal here is efficiency. Async thread offload adds latency, and
it also adds noticable overhead on items such as adding pages to the
page cache. By allowing proper async buffered read support, we don't
have X threads hammering on the same inode page cache, we have just
the single app actually doing IO.
Series can also be found here:
https://git.kernel.dk/cgit/linux-block/log/?h=async-buffered
or pull from:
git://git.kernel.dk/linux-block async-buffered
fs/block_dev.c | 2 +-
fs/btrfs/file.c | 2 +-
fs/ext4/file.c | 2 +-
fs/io_uring.c | 101 ++++++++++++++++++++++++++++++++++++++
fs/xfs/xfs_file.c | 2 +-
include/linux/blk_types.h | 3 +-
include/linux/fs.h | 5 ++
include/linux/pagemap.h | 40 +++++++++++++++
mm/filemap.c | 71 +++++++++++++++++++++------
9 files changed, 207 insertions(+), 21 deletions(-)
--
Jens Axboe
next reply other threads:[~2020-05-22 20:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-22 20:23 Jens Axboe [this message]
2020-05-22 20:23 ` [PATCH 01/11] block: read-ahead submission should imply no-wait as well Jens Axboe
2020-05-22 20:23 ` [PATCH 02/11] mm: allow read-ahead with IOCB_NOWAIT set Jens Axboe
2020-05-22 20:23 ` [PATCH 03/11] mm: add support for async page locking Jens Axboe
2020-05-22 20:57 ` [PATCH v2 " Jens Axboe
2020-05-22 20:23 ` [PATCH 04/11] mm: support async buffered reads in generic_file_buffered_read() Jens Axboe
2020-05-22 20:23 ` [PATCH 05/11] fs: add FMODE_BUF_RASYNC Jens Axboe
2020-05-22 20:23 ` [PATCH 06/11] ext4: flag as supporting buffered async reads Jens Axboe
2020-05-22 20:23 ` [PATCH 07/11] block: flag block devices as supporting IOCB_WAITQ Jens Axboe
2020-05-22 20:23 ` [PATCH 08/11] xfs: flag files as supporting buffered async reads Jens Axboe
2020-05-22 20:23 ` [PATCH 09/11] btrfs: " Jens Axboe
2020-05-22 20:23 ` [PATCH 10/11] mm: add kiocb_wait_page_async_init() helper Jens Axboe
2020-05-22 20:23 ` [PATCH 11/11] io_uring: support true async buffered reads, if file provides it 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] \
[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