public inbox for linux-bcachefs@vger.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: linux-bcachefs@vger.kernel.org
Subject: [PATCH 2/2] bcachefs: remove writeback bio size limit
Date: Wed, 27 Sep 2023 07:23:38 -0400	[thread overview]
Message-ID: <20230927112338.262207-3-bfoster@redhat.com> (raw)
In-Reply-To: <20230927112338.262207-1-bfoster@redhat.com>

The bcachefs folio writeback code includes a bio full check as well
as a fixed size check when it determines whether to submit the
current write op or continue to add to the current bio. The current
code submits prematurely when the current folio fits exactly in the
remaining space allowed in the current bio, which typically results
in an extent merge that would have otherwise been unnecessary. This
can be observed with a buffered write sized exactly to the current
maximum value (1MB) and with key_merging_disabled=1. The latter
prevents the merge from the second write such that a subsequent
check of the extent list shows a 1020k extent followed by a
contiguous 4k extent.

It's not totally clear why the fixed write size check exists.
bio_full() already checks that the bio can accommodate the current
dirty range being processed, so the only other concern is write
latency. Even then, a 1MB cap seems rather small. For reference,
iomap includes a folio batch size (of 4k) to mitigate latency
associated with writeback completion folio processing, but that
restricts writeback bios to somewhere in the range of 16MB-256MB
depending on folio size (i.e. considering 4k to 64k pages). Unless
there is some known reason for it, remove the size limit and rely on
bio_full() to cap the size of the bio.

Signed-off-by: Brian Foster <bfoster@redhat.com>
---
 fs/bcachefs/fs-io-buffered.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/fs/bcachefs/fs-io-buffered.c b/fs/bcachefs/fs-io-buffered.c
index 58ccc7b91ac7..d438b93a3a30 100644
--- a/fs/bcachefs/fs-io-buffered.c
+++ b/fs/bcachefs/fs-io-buffered.c
@@ -607,8 +607,6 @@ static int __bch2_writepage(struct folio *folio,
 		if (w->io &&
 		    (w->io->op.res.nr_replicas != nr_replicas_this_write ||
 		     bio_full(&w->io->op.wbio.bio, sectors << 9) ||
-		     w->io->op.wbio.bio.bi_iter.bi_size + (sectors << 9) >=
-		     (BIO_MAX_VECS * PAGE_SIZE) ||
 		     bio_end_sector(&w->io->op.wbio.bio) != sector))
 			bch2_writepage_do_io(w);
 
-- 
2.41.0


  parent reply	other threads:[~2023-09-27 11:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-27 11:23 [PATCH 0/2] bcachefs: checksum merge and writeback fix Brian Foster
2023-09-27 11:23 ` [PATCH 1/2] bcachefs: fix crc32c checksum merge byte order problem Brian Foster
2023-09-27 22:08   ` Kent Overstreet
2023-09-28 14:12     ` Brian Foster
2023-09-28 16:57       ` Kent Overstreet
2023-09-29  8:13         ` Janpieter Sollie
2023-09-27 11:23 ` Brian Foster [this message]
2023-09-27 22:03   ` [PATCH 2/2] bcachefs: remove writeback bio size limit Kent Overstreet
2023-09-29 14:31     ` Brian Foster

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=20230927112338.262207-3-bfoster@redhat.com \
    --to=bfoster@redhat.com \
    --cc=linux-bcachefs@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox