From: Chao Yu via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: Yongpeng Yang <yangyongpeng.storage@gmail.com>,
Jaegeuk Kim <jaegeuk@kernel.org>
Cc: Yongpeng Yang <yangyongpeng@xiaomi.com>,
Yongpeng Yang <monty_pavel@sina.com>,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH RESEND 2/5] f2fs: only initialize largest extent without extent_node at inode init
Date: Mon, 15 Jun 2026 19:55:54 +0800 [thread overview]
Message-ID: <7ffe0789-1024-4dc7-9089-2dcf856a1bd1@kernel.org> (raw)
In-Reply-To: <20260612115839.2065903-3-yangyongpeng.storage@gmail.com>
On 6/12/26 19:58, Yongpeng Yang wrote:
> From: Yongpeng Yang <yangyongpeng@xiaomi.com>
>
> The largest extent takes effect during both read mapping and write
> mapping lookups, while read mapping does not need to access the
> extent_node. For write mapping, the case where the largest extent is
> not in the extent tree can already be handled by the merge logic, and
> cases that cannot be merged do not require the largest extent to
> participate either.
>
> Therefore, the largest extent does not need to initialize a
> corresponding extent_node, reducing memory footprint.
>
> Signed-off-by: Yongpeng Yang <yangyongpeng@xiaomi.com>
> ---
> fs/f2fs/extent_cache.c | 18 +-----------------
> 1 file changed, 1 insertion(+), 17 deletions(-)
>
> diff --git a/fs/f2fs/extent_cache.c b/fs/f2fs/extent_cache.c
> index aa368a01b035..f8d94db60dc6 100644
> --- a/fs/f2fs/extent_cache.c
> +++ b/fs/f2fs/extent_cache.c
> @@ -410,10 +410,8 @@ static void __drop_largest_extent(struct extent_tree *et,
> void f2fs_init_read_extent_tree(struct inode *inode, struct folio *ifolio)
> {
> struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
> - struct extent_tree_info *eti = &sbi->extent_tree[EX_READ];
> struct f2fs_extent *i_ext = &F2FS_INODE(ifolio)->i_ext;
> struct extent_tree *et;
> - struct extent_node *en;
> struct extent_info ei = {0};
>
> if (!__may_extent_tree(inode, EX_READ)) {
> @@ -435,21 +433,7 @@ void f2fs_init_read_extent_tree(struct inode *inode, struct folio *ifolio)
> if (atomic_read(&et->node_cnt) || !ei.len)
> goto skip;
>
> - if (IS_DEVICE_ALIASING(inode)) {
> - et->largest = ei;
> - goto skip;
> - }
> -
> - en = __attach_extent_node(sbi, et, &ei, NULL,
> - &et->root.rb_root.rb_node, true);
> - if (en) {
> - et->largest = en->ei;
> - et->cached_en = en;
> -
> - spin_lock(&eti->extent_lock);
> - list_add_tail(&en->list, &eti->extent_list);
> - spin_unlock(&eti->extent_lock);
> - }
> + et->largest = ei;
Previously, we can split largest extent node to two if we punched it, now
we can not? IIUC.
Thanks,
> skip:
> /* Let's drop, if checkpoint got corrupted. */
> if (f2fs_cp_error(sbi)) {
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2026-06-15 11:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-12 11:58 [f2fs-dev] [PATCH RESEND 1/5] f2fs: fix extent merge failure when largest extent is not in rb-tree Yongpeng Yang
2026-06-12 11:58 ` [f2fs-dev] [PATCH RESEND 2/5] f2fs: only initialize largest extent without extent_node at inode init Yongpeng Yang
2026-06-15 11:55 ` Chao Yu via Linux-f2fs-devel [this message]
2026-06-12 11:58 ` [f2fs-dev] [PATCH RESEND 3/5] f2fs: punch largest extent instead of dropping it entirely on overlap Yongpeng Yang
2026-06-15 12:05 ` Chao Yu via Linux-f2fs-devel
2026-06-12 11:58 ` [f2fs-dev] [PATCH RESEND 4/5] f2fs: add extent_access_mode to track extent cache access patterns Yongpeng Yang
2026-06-15 12:05 ` Chao Yu via Linux-f2fs-devel
2026-06-12 11:58 ` [f2fs-dev] [PATCH RESEND 5/5] f2fs: add ioctl to export read extent cache to userspace for debug Yongpeng Yang
2026-06-15 12:20 ` Chao Yu via Linux-f2fs-devel
2026-06-15 15:51 ` Jaegeuk Kim via Linux-f2fs-devel
2026-06-15 11:26 ` [f2fs-dev] [PATCH RESEND 1/5] f2fs: fix extent merge failure when largest extent is not in rb-tree Chao Yu via Linux-f2fs-devel
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=7ffe0789-1024-4dc7-9089-2dcf856a1bd1@kernel.org \
--to=linux-f2fs-devel@lists.sourceforge.net \
--cc=chao@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=monty_pavel@sina.com \
--cc=yangyongpeng.storage@gmail.com \
--cc=yangyongpeng@xiaomi.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.