linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
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

  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).