All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joseph Qi <jiangqi903@gmail.com>
To: Zhang Yi <yi.zhang@huaweicloud.com>, 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,
	naresh.kamboju@linaro.org, yi.zhang@huawei.com,
	libaokun1@huawei.com, yukuai3@huawei.com, yangerkun@huawei.com
Subject: Re: [PATCH v4 11/11] ext4: limit the maximum folio order
Date: Tue, 8 Jul 2025 12:04:06 +0800	[thread overview]
Message-ID: <17009dd5-fd3e-4d1d-92df-3ba9cdf666cc@gmail.com> (raw)
In-Reply-To: <20250707140814.542883-12-yi.zhang@huaweicloud.com>



On 2025/7/7 22:08, Zhang Yi wrote:
> From: Zhang Yi <yi.zhang@huawei.com>
> 
> In environments with a page size of 64KB, the maximum size of a folio
> can reach up to 128MB. Consequently, during the write-back of folios,
> the 'rsv_blocks' will be overestimated to 1,577, which can make
> pressure on the journal space where the journal is small. This can
> easily exceed the limit of a single transaction. Besides, an excessively
> large folio is meaningless and will instead increase the overhead of
> traversing the bhs within the folio. Therefore, limit the maximum order
> of a folio to 2048 filesystem blocks.
> 
> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> Reported-by: Joseph Qi <jiangqi903@gmail.com>
> Closes: https://lore.kernel.org/linux-ext4/CA+G9fYsyYQ3ZL4xaSg1-Tt5Evto7Zd+hgNWZEa9cQLbahA1+xg@mail.gmail.com/
> Signed-off-by: Zhang Yi <yi.zhang@huawei.com>

Confirmed that this can fix the following jbd2 warning in start_this_handle():
"JBD2: kworker/u32:0 wants too many credits credits:32 rsv_credits:1577 max:2695"

Tested-by: Joseph Qi <joseph.qi@linux.alibaba.com>

> ---
>  fs/ext4/ext4.h   |  2 +-
>  fs/ext4/ialloc.c |  3 +--
>  fs/ext4/inode.c  | 22 +++++++++++++++++++---
>  3 files changed, 21 insertions(+), 6 deletions(-)
> 
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index f705046ba6c6..9ac0a7d4fa0c 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -3020,7 +3020,7 @@ int ext4_walk_page_buffers(handle_t *handle,
>  				     struct buffer_head *bh));
>  int do_journal_get_write_access(handle_t *handle, struct inode *inode,
>  				struct buffer_head *bh);
> -bool ext4_should_enable_large_folio(struct inode *inode);
> +void ext4_set_inode_mapping_order(struct inode *inode);
>  #define FALL_BACK_TO_NONDELALLOC 1
>  #define CONVERT_INLINE_DATA	 2
>  
> diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
> index 79aa3df8d019..df4051613b29 100644
> --- a/fs/ext4/ialloc.c
> +++ b/fs/ext4/ialloc.c
> @@ -1335,8 +1335,7 @@ struct inode *__ext4_new_inode(struct mnt_idmap *idmap,
>  		}
>  	}
>  
> -	if (ext4_should_enable_large_folio(inode))
> -		mapping_set_large_folios(inode->i_mapping);
> +	ext4_set_inode_mapping_order(inode);
>  
>  	ext4_update_inode_fsync_trans(handle, inode, 1);
>  
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 4b679cb6c8bd..1bce9ebaedb7 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -5181,7 +5181,7 @@ static int check_igot_inode(struct inode *inode, ext4_iget_flags flags,
>  	return -EFSCORRUPTED;
>  }
>  
> -bool ext4_should_enable_large_folio(struct inode *inode)
> +static bool ext4_should_enable_large_folio(struct inode *inode)
>  {
>  	struct super_block *sb = inode->i_sb;
>  
> @@ -5198,6 +5198,22 @@ bool ext4_should_enable_large_folio(struct inode *inode)
>  	return true;
>  }
>  
> +/*
> + * Limit the maximum folio order to 2048 blocks to prevent overestimation
> + * of reserve handle credits during the folio writeback in environments
> + * where the PAGE_SIZE exceeds 4KB.
> + */
> +#define EXT4_MAX_PAGECACHE_ORDER(i)		\
> +		min(MAX_PAGECACHE_ORDER, (11 + (i)->i_blkbits - PAGE_SHIFT))
> +void ext4_set_inode_mapping_order(struct inode *inode)
> +{
> +	if (!ext4_should_enable_large_folio(inode))
> +		return;
> +
> +	mapping_set_folio_order_range(inode->i_mapping, 0,
> +				      EXT4_MAX_PAGECACHE_ORDER(inode));
> +}
> +
>  struct inode *__ext4_iget(struct super_block *sb, unsigned long ino,
>  			  ext4_iget_flags flags, const char *function,
>  			  unsigned int line)
> @@ -5515,8 +5531,8 @@ struct inode *__ext4_iget(struct super_block *sb, unsigned long ino,
>  		ret = -EFSCORRUPTED;
>  		goto bad_inode;
>  	}
> -	if (ext4_should_enable_large_folio(inode))
> -		mapping_set_large_folios(inode->i_mapping);
> +
> +	ext4_set_inode_mapping_order(inode);
>  
>  	ret = check_igot_inode(inode, flags, function, line);
>  	/*


  parent reply	other threads:[~2025-07-08  4:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-07 14:08 [PATCH v4 00/11] ext4: fix insufficient credits when writing back large folios Zhang Yi
2025-07-07 14:08 ` [PATCH v4 01/11] ext4: process folios writeback in bytes Zhang Yi
2025-07-07 14:08 ` [PATCH v4 02/11] ext4: move the calculation of wbc->nr_to_write to mpage_folio_done() Zhang Yi
2025-07-07 14:08 ` [PATCH v4 03/11] ext4: fix stale data if it bail out of the extents mapping loop Zhang Yi
2025-07-07 14:08 ` [PATCH v4 04/11] ext4: refactor the block allocation process of ext4_page_mkwrite() Zhang Yi
2025-07-07 14:08 ` [PATCH v4 05/11] ext4: restart handle if credits are insufficient during allocating blocks Zhang Yi
2025-07-07 14:08 ` [PATCH v4 06/11] ext4: enhance tracepoints during the folios writeback Zhang Yi
2025-07-07 14:08 ` [PATCH v4 07/11] ext4: correct the reserved credits for extent conversion Zhang Yi
2025-07-07 14:08 ` [PATCH v4 08/11] ext4: reserved credits for one extent during the folio writeback Zhang Yi
2025-07-07 14:08 ` [PATCH v4 09/11] ext4: replace ext4_writepage_trans_blocks() Zhang Yi
2025-07-07 14:08 ` [PATCH v4 10/11] ext4: fix insufficient credits calculation in ext4_meta_trans_blocks() Zhang Yi
2025-07-07 14:08 ` [PATCH v4 11/11] ext4: limit the maximum folio order Zhang Yi
2025-07-07 16:37   ` Jan Kara
2025-07-08  4:04   ` Joseph Qi [this message]
2025-07-10 12:12   ` Naresh Kamboju
2025-07-09  7:53 ` [PATCH v4 00/11] ext4: fix insufficient credits when writing back large folios Naresh Kamboju
2025-07-14 17:46 ` Theodore Ts'o

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=17009dd5-fd3e-4d1d-92df-3ba9cdf666cc@gmail.com \
    --to=jiangqi903@gmail.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=naresh.kamboju@linaro.org \
    --cc=ojaswin@linux.ibm.com \
    --cc=sashal@kernel.org \
    --cc=tytso@mit.edu \
    --cc=yangerkun@huawei.com \
    --cc=yi.zhang@huawei.com \
    --cc=yi.zhang@huaweicloud.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 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.