From: Zhang Yi <yi.zhang@huaweicloud.com>
To: linux-ext4@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz,
ojaswin@linux.ibm.com, sashal@kernel.org, yi.zhang@huawei.com,
yi.zhang@huaweicloud.com, libaokun1@huawei.com,
yukuai3@huawei.com, yangerkun@huawei.com
Subject: [PATCH v3 08/10] ext4: reserved credits for one extent during the folio writeback
Date: Tue, 1 Jul 2025 21:06:33 +0800 [thread overview]
Message-ID: <20250701130635.4079595-9-yi.zhang@huaweicloud.com> (raw)
In-Reply-To: <20250701130635.4079595-1-yi.zhang@huaweicloud.com>
From: Zhang Yi <yi.zhang@huawei.com>
After ext4 supports large folios, reserving journal credits for one
maximum-ordered folio based on the worst case cenario during the
writeback process can easily exceed the maximum transaction credits.
Additionally, reserving journal credits for one page is also no
longer appropriate.
Currently, the folio writeback process can either extend the journal
credits or initiate a new transaction if the currently reserved journal
credits are insufficient. Therefore, it can be modified to reserve
credits for only one extent at the outset. In most cases involving
continuous mapping, these credits are generally adequate, and we may
only need to perform some basic credit expansion. However, in extreme
cases where the block size and folio size differ significantly, or when
the folios are sufficiently discontinuous, it may be necessary to
restart a new transaction and resubmit the folios.
Suggested-by: Jan Kara <jack@suse.cz>
Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
---
fs/ext4/inode.c | 25 ++++++++-----------------
1 file changed, 8 insertions(+), 17 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 3230734a3014..ceaede80d791 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -2546,21 +2546,6 @@ static int mpage_map_and_submit_extent(handle_t *handle,
return err;
}
-/*
- * Calculate the total number of credits to reserve for one writepages
- * iteration. This is called from ext4_writepages(). We map an extent of
- * up to MAX_WRITEPAGES_EXTENT_LEN blocks and then we go on and finish mapping
- * the last partial page. So in total we can map MAX_WRITEPAGES_EXTENT_LEN +
- * bpp - 1 blocks in bpp different extents.
- */
-static int ext4_da_writepages_trans_blocks(struct inode *inode)
-{
- int bpp = ext4_journal_blocks_per_folio(inode);
-
- return ext4_meta_trans_blocks(inode,
- MAX_WRITEPAGES_EXTENT_LEN + bpp - 1, bpp);
-}
-
static int ext4_journal_folio_buffers(handle_t *handle, struct folio *folio,
size_t len)
{
@@ -2917,8 +2902,14 @@ static int ext4_do_writepages(struct mpage_da_data *mpd)
* not supported by delalloc.
*/
BUG_ON(ext4_should_journal_data(inode));
- needed_blocks = ext4_da_writepages_trans_blocks(inode);
-
+ /*
+ * Calculate the number of credits needed to reserve for one
+ * extent of up to MAX_WRITEPAGES_EXTENT_LEN blocks. It will
+ * attempt to extend the transaction or start a new iteration
+ * if the reserved credits are insufficient.
+ */
+ needed_blocks = ext4_chunk_trans_blocks(inode,
+ MAX_WRITEPAGES_EXTENT_LEN);
/* start a new transaction */
handle = ext4_journal_start_with_reserve(inode,
EXT4_HT_WRITE_PAGE, needed_blocks, rsv_blocks);
--
2.46.1
next prev parent reply other threads:[~2025-07-01 13:21 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-01 13:06 [PATCH v3 00/10] ext4: fix insufficient credits when writing back large folios Zhang Yi
2025-07-01 13:06 ` [PATCH v3 01/10] ext4: process folios writeback in bytes Zhang Yi
2025-07-02 14:00 ` Jan Kara
2025-07-03 2:03 ` Zhang Yi
2025-07-01 13:06 ` [PATCH v3 02/10] ext4: move the calculation of wbc->nr_to_write to mpage_folio_done() Zhang Yi
2025-07-01 13:06 ` [PATCH v3 03/10] ext4: fix stale data if it bail out of the extents mapping loop Zhang Yi
2025-07-02 14:07 ` Jan Kara
2025-07-03 2:05 ` Zhang Yi
2025-07-01 13:06 ` [PATCH v3 04/10] ext4: refactor the block allocation process of ext4_page_mkwrite() Zhang Yi
2025-07-02 14:10 ` Jan Kara
2025-07-01 13:06 ` [PATCH v3 05/10] ext4: restart handle if credits are insufficient during allocating blocks Zhang Yi
2025-07-02 14:18 ` Jan Kara
2025-07-03 2:13 ` Zhang Yi
2025-07-03 16:27 ` Jan Kara
2025-07-04 1:40 ` Zhang Yi
2025-07-04 8:18 ` Jan Kara
2025-07-04 8:47 ` Zhang Yi
2025-07-01 13:06 ` [PATCH v3 06/10] ext4: enhance tracepoints during the folios writeback Zhang Yi
2025-07-02 14:20 ` Jan Kara
2025-07-01 13:06 ` [PATCH v3 07/10] ext4: correct the reserved credits for extent conversion Zhang Yi
2025-07-01 13:06 ` Zhang Yi [this message]
2025-07-02 14:34 ` [PATCH v3 08/10] ext4: reserved credits for one extent during the folio writeback Jan Kara
2025-07-01 13:06 ` [PATCH v3 09/10] ext4: replace ext4_writepage_trans_blocks() Zhang Yi
2025-07-02 14:50 ` Jan Kara
2025-07-01 13:06 ` [PATCH v3 10/10] ext4: fix insufficient credits calculation in ext4_meta_trans_blocks() Zhang Yi
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=20250701130635.4079595-9-yi.zhang@huaweicloud.com \
--to=yi.zhang@huaweicloud.com \
--cc=adilger.kernel@dilger.ca \
--cc=jack@suse.cz \
--cc=libaokun1@huawei.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=sashal@kernel.org \
--cc=tytso@mit.edu \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yukuai3@huawei.com \
/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;
as well as URLs for NNTP newsgroup(s).