All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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.