From: Jaegeuk Kim via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: Liao Yuanhong <liaoyuanhong@vivo.com>
Cc: open list <linux-kernel@vger.kernel.org>,
"open list:F2FS FILE SYSTEM"
<linux-f2fs-devel@lists.sourceforge.net>
Subject: Re: [f2fs-dev] [PATCH 1/2] f2fs: Optimize excessive write operations caused by continuous background garbage collection in Zoned UFS
Date: Tue, 16 Sep 2025 02:28:03 +0000 [thread overview]
Message-ID: <aMjLMwNDjabD8MVH@google.com> (raw)
In-Reply-To: <20250909134418.502922-2-liaoyuanhong@vivo.com>
Could you please share some trends of relation between has_enough_free_blocks()
vs. has_enough_dirty_blocks()? I'm wondering whethere there's a missing case
where has_enough_free_blocks() is not enough.
On 09/09, Liao Yuanhong wrote:
> Incorporate a check using has_enough_dirty_blocks() to prevent redundant
> background GC in Zoned UFS. When there are insufficient dirty segments,
> continuous execution of background GC should be avoided, as it results in
> unnecessary write operations and impacts device lifespan. The initial
> threshold is set to 3 * section size (since f2fs data uses three write
> pointers).
>
> Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com>
> ---
> fs/f2fs/gc.c | 8 ++++++--
> fs/f2fs/gc.h | 10 +++++++++-
> 2 files changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> index ed3acbfc83ca..4a8c08f970e3 100644
> --- a/fs/f2fs/gc.c
> +++ b/fs/f2fs/gc.c
> @@ -120,7 +120,9 @@ static int gc_thread_func(void *data)
>
> if (f2fs_sb_has_blkzoned(sbi)) {
> if (has_enough_free_blocks(sbi,
> - gc_th->no_zoned_gc_percent)) {
> + gc_th->no_zoned_gc_percent) ||
> + !has_enough_dirty_blocks(sbi,
> + LIMIT_GC_DIRTY_SECTION_NUM)) {
> wait_ms = gc_th->no_gc_sleep_time;
> f2fs_up_write(&sbi->gc_lock);
> goto next;
> @@ -1750,7 +1752,9 @@ static int do_garbage_collect(struct f2fs_sb_info *sbi,
>
> if (f2fs_sb_has_blkzoned(sbi) &&
> !has_enough_free_blocks(sbi,
> - sbi->gc_thread->boost_zoned_gc_percent))
> + sbi->gc_thread->boost_zoned_gc_percent) &&
> + has_enough_dirty_blocks(sbi,
> + LIMIT_GC_DIRTY_SECTION_NUM))
> window_granularity *=
> sbi->gc_thread->boost_gc_multiple;
>
> diff --git a/fs/f2fs/gc.h b/fs/f2fs/gc.h
> index 24e8b1c27acc..1ef234c2702b 100644
> --- a/fs/f2fs/gc.h
> +++ b/fs/f2fs/gc.h
> @@ -36,6 +36,7 @@
> #define DEF_MIGRATION_WINDOW_GRANULARITY_ZONED 3
> #define BOOST_GC_MULTIPLE 5
> #define ZONED_PIN_SEC_REQUIRED_COUNT 1
> +#define LIMIT_GC_DIRTY_SECTION_NUM 3
>
> #define DEF_GC_FAILED_PINNED_FILES 2048
> #define MAX_GC_FAILED_PINNED_FILES USHRT_MAX
> @@ -177,6 +178,12 @@ static inline bool has_enough_free_blocks(struct f2fs_sb_info *sbi,
> return free_sections(sbi) > ((sbi->total_sections * limit_perc) / 100);
> }
>
> +static inline bool has_enough_dirty_blocks(struct f2fs_sb_info *sbi,
> + unsigned int limit_num)
> +{
> + return dirty_segments(sbi) > limit_num * SEGS_PER_SEC(sbi);
> +}
> +
> static inline bool has_enough_invalid_blocks(struct f2fs_sb_info *sbi)
> {
> block_t user_block_count = sbi->user_block_count;
> @@ -197,6 +204,7 @@ static inline bool need_to_boost_gc(struct f2fs_sb_info *sbi)
> {
> if (f2fs_sb_has_blkzoned(sbi))
> return !has_enough_free_blocks(sbi,
> - sbi->gc_thread->boost_zoned_gc_percent);
> + sbi->gc_thread->boost_zoned_gc_percent) &&
> + has_enough_dirty_blocks(sbi, LIMIT_GC_DIRTY_SECTION_NUM);
> return has_enough_invalid_blocks(sbi);
> }
> --
> 2.34.1
_______________________________________________
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:[~2025-09-16 2:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-09 13:44 [f2fs-dev] [PATCH 0/2] f2fs: Some optimizations for background GC in Zoned UFS Liao Yuanhong via Linux-f2fs-devel
2025-09-09 13:44 ` [f2fs-dev] [PATCH 1/2] f2fs: Optimize excessive write operations caused by continuous background garbage collection " Liao Yuanhong via Linux-f2fs-devel
2025-09-15 8:25 ` Chao Yu via Linux-f2fs-devel
2025-09-16 2:28 ` Jaegeuk Kim via Linux-f2fs-devel [this message]
2025-09-17 7:15 ` Liao Yuanhong via Linux-f2fs-devel
2025-09-09 13:44 ` [f2fs-dev] [PATCH 2/2] f2fs: Enhance the subsequent logic of valid_thresh_ratio to prevent unnecessary background GC Liao Yuanhong via Linux-f2fs-devel
2025-09-15 8:36 ` Chao Yu via Linux-f2fs-devel
2025-09-17 7:08 ` Liao Yuanhong via Linux-f2fs-devel
2025-09-17 7:57 ` Chao Yu via Linux-f2fs-devel
2025-09-17 8:13 ` Liao Yuanhong via Linux-f2fs-devel
2025-09-18 2:16 ` Chao Yu via Linux-f2fs-devel
2025-09-20 2:49 ` Liao Yuanhong via Linux-f2fs-devel
2025-09-23 6:43 ` 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=aMjLMwNDjabD8MVH@google.com \
--to=linux-f2fs-devel@lists.sourceforge.net \
--cc=jaegeuk@kernel.org \
--cc=liaoyuanhong@vivo.com \
--cc=linux-kernel@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;
as well as URLs for NNTP newsgroup(s).