public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chao Yu <chao@kernel.org>
To: Yangtao Li <frank.li@vivo.com>, jaegeuk@kernel.org
Cc: linux-f2fs-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, kernel test robot <lkp@intel.com>
Subject: Re: [PATCH v2] f2fs: don't call f2fs_issue_discard_timeout() when discard_cmd_cnt is 0 in f2fs_put_super()
Date: Sun, 11 Dec 2022 10:27:18 +0800	[thread overview]
Message-ID: <3f2c81f8-7946-d2e0-8768-6f0b03282944@kernel.org> (raw)
In-Reply-To: <20221202045841.9888-1-frank.li@vivo.com>

On 2022/12/2 12:58, Yangtao Li wrote:
> No need to call f2fs_issue_discard_timeout() in f2fs_put_super,
> when no discard command requires issue. Since the caller of
> f2fs_issue_discard_timeout() usually judges the number of discard
> commands before using it. Let's move this logic to
> f2fs_issue_discard_timeout().
> 
> By the way, use f2fs_realtime_discard_enable to simplify the code.
> 
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Yangtao Li <frank.li@vivo.com>
> ---
>   fs/f2fs/segment.c | 6 ++++--
>   fs/f2fs/super.c   | 8 ++------
>   2 files changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index 9486ca49ecb1..d5f150a08285 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -1655,6 +1655,9 @@ bool f2fs_issue_discard_timeout(struct f2fs_sb_info *sbi)
>   	struct discard_policy dpolicy;
>   	bool dropped;
>   
> +	if (!atomic_read(&dcc->discard_cmd_cnt))
> +		return false;
> +
>   	__init_discard_policy(sbi, &dpolicy, DPOLICY_UMOUNT,
>   					dcc->discard_granularity);
>   	__issue_discard_cmd(sbi, &dpolicy);
> @@ -2110,8 +2113,7 @@ static void destroy_discard_cmd_control(struct f2fs_sb_info *sbi)
>   	 * Recovery can cache discard commands, so in error path of
>   	 * fill_super(), it needs to give a chance to handle them.
>   	 */
> -	if (unlikely(atomic_read(&dcc->discard_cmd_cnt)))
> -		f2fs_issue_discard_timeout(sbi);
> +	f2fs_issue_discard_timeout(sbi);
>   
>   	kfree(dcc);
>   	SM_I(sbi)->dcc_info = NULL;
> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> index 79bf1faf4161..aa1cadfd34a5 100644
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@ -1576,8 +1576,7 @@ static void f2fs_put_super(struct super_block *sb)
>   	/* be sure to wait for any on-going discard commands */
>   	dropped = f2fs_issue_discard_timeout(sbi);
>   
> -	if ((f2fs_hw_support_discard(sbi) || f2fs_hw_should_discard(sbi)) &&
> -					!sbi->discard_blks && !dropped) {
> +	if (f2fs_realtime_discard_enable(sbi) && !sbi->discard_blks && !dropped) {

static inline bool f2fs_realtime_discard_enable(struct f2fs_sb_info *sbi)
{
	return (test_opt(sbi, DISCARD) && f2fs_hw_support_discard(sbi)) ||
					f2fs_hw_should_discard(sbi);
}

It looks the logic is changed?

Thanks,


>   		struct cp_control cpc = {
>   			.reason = CP_UMOUNT | CP_TRIMMED,
>   		};
> @@ -2225,7 +2224,6 @@ static int f2fs_remount(struct super_block *sb, int *flags, char *data)
>   	bool no_discard = !test_opt(sbi, DISCARD);
>   	bool no_compress_cache = !test_opt(sbi, COMPRESS_CACHE);
>   	bool block_unit_discard = f2fs_block_unit_discard(sbi);
> -	struct discard_cmd_control *dcc;
>   #ifdef CONFIG_QUOTA
>   	int i, j;
>   #endif
> @@ -2406,10 +2404,8 @@ static int f2fs_remount(struct super_block *sb, int *flags, char *data)
>   				goto restore_flush;
>   			need_stop_discard = true;
>   		} else {
> -			dcc = SM_I(sbi)->dcc_info;
>   			f2fs_stop_discard_thread(sbi);
> -			if (atomic_read(&dcc->discard_cmd_cnt))
> -				f2fs_issue_discard_timeout(sbi);
> +			f2fs_issue_discard_timeout(sbi);
>   			need_restart_discard = true;
>   		}
>   	}

  reply	other threads:[~2022-12-11  2:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-02  4:58 [PATCH v2] f2fs: don't call f2fs_issue_discard_timeout() when discard_cmd_cnt is 0 in f2fs_put_super() Yangtao Li
2022-12-11  2:27 ` Chao Yu [this message]
2022-12-12 13:05   ` Yangtao Li
2022-12-12 13:50     ` Chao Yu
2022-12-12 14:14       ` Yangtao Li
2022-12-12 14:34         ` Chao Yu
2022-12-12 22:45           ` Jaegeuk Kim
2022-12-13  1:32             ` Chao Yu
2022-12-13  1:41               ` Jaegeuk Kim

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=3f2c81f8-7946-d2e0-8768-6f0b03282944@kernel.org \
    --to=chao@kernel.org \
    --cc=frank.li@vivo.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.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