From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v4 0/2] btrfs: go extent-by-extent submission for buffered reads and writes
Date: Mon, 5 Oct 2026 11:46:36 +1030 [thread overview]
Message-ID: <cover.1791162950.git.wqu@suse.com> (raw)
[CHANGELOG]
v4:
- Make the writeback_bio_size limit check more robust
Only clamp @cur_len and do round_up() when the writeback_bio_size is
larger than the current bio size.
This will handle unaligned writeback_bio_size more robustly.
v3:
- Enhance the writeback_bio_size limit check
Now we limit the writeback size early.
This will follow the writeback_bio_size better.
- Do a better microbenchmark for the writeback patch
It turns out that writeback throttle is making submit_bio() sleep,
masking the improvement in extent_writepage_io().
With wbt_late_nsec set to 0, now the improvement is way more obvious.
Now it's over 90% reduce in average runtime, other than no improvement
in the average runtime.
v2:
- Fix the length of advancement when no OE is found
We should still retry the next block, as there may be only a block of
gap.
Exposed by Sashiko on the 2nd patch.
Although it also exposed a false alert on the
truncate_ordered_extents_beyond_eof().
Where all the blocks in the range should have an OE, or we're having
a bigger problem.
Although we have large data folio support for a while, the buffered
reads and writes are still iterating a large folio block-by-block.
For a large buffered IO, the large folio has a very high chance to
contain only one single extent.
In that case, although doing block-by-block checks is good for
readability, it's not really performant.
The series changes the behavior to do extent-by-extent iteration
instead, this can bring a very slight performance improve.
For best case scenario, the runtime to submit a folio read can be
reduced from 32us to 2.5us, and a much better distribution.
The runtime to submit a folio write can be reduced from 177us to 9us.
Qu Wenruo (2):
btrfs: read a folio extent-by-extent instead of block-by-block
btrfs: write back a folio extent-by-extent instead of block-by-block
fs/btrfs/extent_io.c | 323 ++++++++++++++++++++++++++-----------------
fs/btrfs/subpage.c | 49 +++++++
fs/btrfs/subpage.h | 4 +
3 files changed, 247 insertions(+), 129 deletions(-)
--
2.55.0
next reply other threads:[~2026-10-05 1:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-05 1:16 Qu Wenruo [this message]
2026-10-05 1:16 ` [PATCH v4 1/2] btrfs: read a folio extent-by-extent instead of block-by-block Qu Wenruo
2026-10-05 1:16 ` [PATCH v4 2/2] btrfs: write back " Qu Wenruo
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=cover.1791162950.git.wqu@suse.com \
--to=wqu@suse.com \
--cc=linux-btrfs@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.