All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sahitya Tummala <stummala@codeaurora.org>
To: Chao Yu <yuchao0@huawei.com>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH] f2fs: fix the discard thread sleep timeout under high utilization
Date: Mon, 15 Mar 2021 15:15:02 +0530	[thread overview]
Message-ID: <20210315094502.GB8562@codeaurora.org> (raw)
In-Reply-To: <0c7220d7-416e-32b7-96cb-effd3f84d6e2@huawei.com>

Hi Chao,

On Mon, Mar 15, 2021 at 04:10:22PM +0800, Chao Yu wrote:
> Hi Sahitya,
> 
> On 2021/3/15 15:46, Sahitya Tummala wrote:
> >Hi Chao,
> >
> >On Mon, Mar 15, 2021 at 02:12:44PM +0800, Chao Yu wrote:
> >>Sahitya,
> >>
> >>On 2021/3/15 12:56, Sahitya Tummala wrote:
> >>>When f2fs is heavily utilized over 80%, the current discard policy
> >>>sets the max sleep timeout of discard thread as 50ms
> >>>(DEF_MIN_DISCARD_ISSUE_TIME). But this is set even when there are
> >>>no pending discard commands to be issued. This results into
> >>>unnecessary frequent and periodic wake ups of the discard thread.
> >>>This patch adds check for pending  discard commands in addition
> >>>to heavy utilization condition to prevent those wake ups.
> >>
> >>Could this commit fix your issue?
> >>
> >>https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev&id=43f8c47ea7d59c7b2270835f1d7c4618a1ea27b6
> >>
> >I don't think it will help because we are changing the max timeout of the
> >dpolicy itself in __init_discard_policy() when util > 80% as below -
> >
> >dpolicy->max_interval = DEF_MIN_DISCARD_ISSUE_TIME;
> >
> >And issue_discard_thread() uses this value as wait_ms, when there
> >are no more pending discard commands to be issued.
> ><snip>
> >                 } else {
> >                         wait_ms = dpolicy.max_interval;
> >                 }
> ><snip>
> >
> >The new patch posted above is not changing anything related to the  max_interval.
> >Hence, I think it won't help the uncessary wakeup problem I am trying to solve
> >for this condition - util > 80% and when there are no pending discards.
> >
> >Please let me know if i am missing something.
> 
> Copied, thanks for the explanation.
> 
> But there is another case which can cause this issue in the case of
> disk util < 80%.
> 
> wait_ms = DEF_MIN_DISCARD_ISSUE_TIME;
> 
> do {
> 	wait_event_interruptible_timeout(, wait_ms);
> 
> 	...
> 
> 	if (!atomic_read(&dcc->discard_cmd_cnt))
> [1] new statement
> 		continue;
> 
> } while();
> 
> Then the loop will wakeup whenever 50ms timeout.
> 
Yes, only for a short period of time i.e., until the first discard command
is issued. Once a discard is issued, it will use 
wait_ms = dpolicy.max_interval;

> So, to avoid this case, shouldn't we reset wait_ms to dpolicy.max_interval
> at [1]?
> 
Yes, we can add that to cover the above case. 

> Meanwhile, how about relocating discard_cmd_cnt check after
> __init_discard_policy(DPOLICY_FORCE)? and olny set .max_interval to
> DEF_MAX_DISCARD_ISSUE_TIME if there is no discard command, and keep
> .granularity to 1?
>

There is not need to change .granularity, right? It will be controlled
as per utilization as it is done today. Only max_interval and wait_ms
needs to be updated. Does this look good?

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index d7076796..958ad1e 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -1772,13 +1772,16 @@ static int issue_discard_thread(void *data)
                        wait_ms = dpolicy.max_interval;
                        continue;
                }
-               if (!atomic_read(&dcc->discard_cmd_cnt))
-                       continue;
-
                if (sbi->gc_mode == GC_URGENT_HIGH ||
                        !f2fs_available_free_memory(sbi, DISCARD_CACHE))
                        __init_discard_policy(sbi, &dpolicy, DPOLICY_FORCE, 1);

+               if (!atomic_read(&dcc->discard_cmd_cnt)) {
+                       dpolicy.max_interval = DEF_MAX_DISCARD_ISSUE_TIME;
+                       wait_ms = dpolicy.max_interval;
+                       continue;
+               }
+
                sb_start_intwrite(sbi->sb);

                issued = __issue_discard_cmd(sbi, &dpolicy);

thanks,
Sahitya.

> Thanks,
> 
> >
> >Thanks,
> >Sahitya.
> >
> >>Thanks,
> >>
> >>>
> >>>Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
> >>>---
> >>>  fs/f2fs/segment.c | 5 ++++-
> >>>  1 file changed, 4 insertions(+), 1 deletion(-)
> >>>
> >>>diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> >>>index dced46c..df30220 100644
> >>>--- a/fs/f2fs/segment.c
> >>>+++ b/fs/f2fs/segment.c
> >>>@@ -1112,6 +1112,8 @@ static void __init_discard_policy(struct f2fs_sb_info *sbi,
> >>>  				struct discard_policy *dpolicy,
> >>>  				int discard_type, unsigned int granularity)
> >>>  {
> >>>+	struct discard_cmd_control *dcc = SM_I(sbi)->dcc_info;
> >>>+
> >>>  	/* common policy */
> >>>  	dpolicy->type = discard_type;
> >>>  	dpolicy->sync = true;
> >>>@@ -1129,7 +1131,8 @@ static void __init_discard_policy(struct f2fs_sb_info *sbi,
> >>>  		dpolicy->io_aware = true;
> >>>  		dpolicy->sync = false;
> >>>  		dpolicy->ordered = true;
> >>>-		if (utilization(sbi) > DEF_DISCARD_URGENT_UTIL) {
> >>>+		if (utilization(sbi) > DEF_DISCARD_URGENT_UTIL &&
> >>>+				atomic_read(&dcc->discard_cmd_cnt)) {
> >>>  			dpolicy->granularity = 1;
> >>>  			dpolicy->max_interval = DEF_MIN_DISCARD_ISSUE_TIME;
> >>>  		}
> >>>
> >

-- 
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

WARNING: multiple messages have this Message-ID (diff)
From: Sahitya Tummala <stummala@codeaurora.org>
To: Chao Yu <yuchao0@huawei.com>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>,
	linux-f2fs-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, stummala@codeaurora.org
Subject: Re: [PATCH] f2fs: fix the discard thread sleep timeout under high utilization
Date: Mon, 15 Mar 2021 15:15:02 +0530	[thread overview]
Message-ID: <20210315094502.GB8562@codeaurora.org> (raw)
In-Reply-To: <0c7220d7-416e-32b7-96cb-effd3f84d6e2@huawei.com>

Hi Chao,

On Mon, Mar 15, 2021 at 04:10:22PM +0800, Chao Yu wrote:
> Hi Sahitya,
> 
> On 2021/3/15 15:46, Sahitya Tummala wrote:
> >Hi Chao,
> >
> >On Mon, Mar 15, 2021 at 02:12:44PM +0800, Chao Yu wrote:
> >>Sahitya,
> >>
> >>On 2021/3/15 12:56, Sahitya Tummala wrote:
> >>>When f2fs is heavily utilized over 80%, the current discard policy
> >>>sets the max sleep timeout of discard thread as 50ms
> >>>(DEF_MIN_DISCARD_ISSUE_TIME). But this is set even when there are
> >>>no pending discard commands to be issued. This results into
> >>>unnecessary frequent and periodic wake ups of the discard thread.
> >>>This patch adds check for pending  discard commands in addition
> >>>to heavy utilization condition to prevent those wake ups.
> >>
> >>Could this commit fix your issue?
> >>
> >>https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev&id=43f8c47ea7d59c7b2270835f1d7c4618a1ea27b6
> >>
> >I don't think it will help because we are changing the max timeout of the
> >dpolicy itself in __init_discard_policy() when util > 80% as below -
> >
> >dpolicy->max_interval = DEF_MIN_DISCARD_ISSUE_TIME;
> >
> >And issue_discard_thread() uses this value as wait_ms, when there
> >are no more pending discard commands to be issued.
> ><snip>
> >                 } else {
> >                         wait_ms = dpolicy.max_interval;
> >                 }
> ><snip>
> >
> >The new patch posted above is not changing anything related to the  max_interval.
> >Hence, I think it won't help the uncessary wakeup problem I am trying to solve
> >for this condition - util > 80% and when there are no pending discards.
> >
> >Please let me know if i am missing something.
> 
> Copied, thanks for the explanation.
> 
> But there is another case which can cause this issue in the case of
> disk util < 80%.
> 
> wait_ms = DEF_MIN_DISCARD_ISSUE_TIME;
> 
> do {
> 	wait_event_interruptible_timeout(, wait_ms);
> 
> 	...
> 
> 	if (!atomic_read(&dcc->discard_cmd_cnt))
> [1] new statement
> 		continue;
> 
> } while();
> 
> Then the loop will wakeup whenever 50ms timeout.
> 
Yes, only for a short period of time i.e., until the first discard command
is issued. Once a discard is issued, it will use 
wait_ms = dpolicy.max_interval;

> So, to avoid this case, shouldn't we reset wait_ms to dpolicy.max_interval
> at [1]?
> 
Yes, we can add that to cover the above case. 

> Meanwhile, how about relocating discard_cmd_cnt check after
> __init_discard_policy(DPOLICY_FORCE)? and olny set .max_interval to
> DEF_MAX_DISCARD_ISSUE_TIME if there is no discard command, and keep
> .granularity to 1?
>

There is not need to change .granularity, right? It will be controlled
as per utilization as it is done today. Only max_interval and wait_ms
needs to be updated. Does this look good?

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index d7076796..958ad1e 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -1772,13 +1772,16 @@ static int issue_discard_thread(void *data)
                        wait_ms = dpolicy.max_interval;
                        continue;
                }
-               if (!atomic_read(&dcc->discard_cmd_cnt))
-                       continue;
-
                if (sbi->gc_mode == GC_URGENT_HIGH ||
                        !f2fs_available_free_memory(sbi, DISCARD_CACHE))
                        __init_discard_policy(sbi, &dpolicy, DPOLICY_FORCE, 1);

+               if (!atomic_read(&dcc->discard_cmd_cnt)) {
+                       dpolicy.max_interval = DEF_MAX_DISCARD_ISSUE_TIME;
+                       wait_ms = dpolicy.max_interval;
+                       continue;
+               }
+
                sb_start_intwrite(sbi->sb);

                issued = __issue_discard_cmd(sbi, &dpolicy);

thanks,
Sahitya.

> Thanks,
> 
> >
> >Thanks,
> >Sahitya.
> >
> >>Thanks,
> >>
> >>>
> >>>Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
> >>>---
> >>>  fs/f2fs/segment.c | 5 ++++-
> >>>  1 file changed, 4 insertions(+), 1 deletion(-)
> >>>
> >>>diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> >>>index dced46c..df30220 100644
> >>>--- a/fs/f2fs/segment.c
> >>>+++ b/fs/f2fs/segment.c
> >>>@@ -1112,6 +1112,8 @@ static void __init_discard_policy(struct f2fs_sb_info *sbi,
> >>>  				struct discard_policy *dpolicy,
> >>>  				int discard_type, unsigned int granularity)
> >>>  {
> >>>+	struct discard_cmd_control *dcc = SM_I(sbi)->dcc_info;
> >>>+
> >>>  	/* common policy */
> >>>  	dpolicy->type = discard_type;
> >>>  	dpolicy->sync = true;
> >>>@@ -1129,7 +1131,8 @@ static void __init_discard_policy(struct f2fs_sb_info *sbi,
> >>>  		dpolicy->io_aware = true;
> >>>  		dpolicy->sync = false;
> >>>  		dpolicy->ordered = true;
> >>>-		if (utilization(sbi) > DEF_DISCARD_URGENT_UTIL) {
> >>>+		if (utilization(sbi) > DEF_DISCARD_URGENT_UTIL &&
> >>>+				atomic_read(&dcc->discard_cmd_cnt)) {
> >>>  			dpolicy->granularity = 1;
> >>>  			dpolicy->max_interval = DEF_MIN_DISCARD_ISSUE_TIME;
> >>>  		}
> >>>
> >

-- 
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

  reply	other threads:[~2021-03-15  9:45 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-15  4:56 [f2fs-dev] [PATCH] f2fs: fix the discard thread sleep timeout under high utilization Sahitya Tummala
2021-03-15  4:56 ` Sahitya Tummala
2021-03-15  6:12 ` [f2fs-dev] " Chao Yu
2021-03-15  6:12   ` Chao Yu
2021-03-15  7:46   ` [f2fs-dev] " Sahitya Tummala
2021-03-15  7:46     ` Sahitya Tummala
2021-03-15  8:10     ` [f2fs-dev] " Chao Yu
2021-03-15  8:10       ` Chao Yu
2021-03-15  9:45       ` Sahitya Tummala [this message]
2021-03-15  9:45         ` Sahitya Tummala
2021-03-15 10:31         ` [f2fs-dev] " Chao Yu
2021-03-15 10:31           ` Chao Yu
2021-03-16  9:34           ` [f2fs-dev] " Sahitya Tummala
2021-03-16  9:34             ` Sahitya Tummala
2021-04-06  9:09             ` [f2fs-dev] [PATCH v2] f2fs: fix the periodic wakeups of discard thread Sahitya Tummala
2021-04-06  9:09               ` Sahitya Tummala
2021-04-06  9:29               ` [f2fs-dev] " Chao Yu
2021-04-06  9:29                 ` Chao Yu

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=20210315094502.GB8562@codeaurora.org \
    --to=stummala@codeaurora.org \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yuchao0@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.