From: Sahitya Tummala <stummala@codeaurora.org>
To: Chao Yu <chao@kernel.org>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>,
linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH] f2fs: fix unnecessary periodic wakeup of discard thread when dev is busy
Date: Sun, 2 Sep 2018 16:04:11 +0530 [thread overview]
Message-ID: <20180902103411.GE12489@codeaurora.org> (raw)
In-Reply-To: <ae0ec622-1fd3-d28a-019b-75a507e551f6@kernel.org>
On Sun, Sep 02, 2018 at 04:52:40PM +0800, Chao Yu wrote:
> On 2018/8/31 17:39, Sahitya Tummala wrote:
> > When dev is busy, discard thread wake up timeout can be aligned with the
> > exact time that it needs to wait for dev to come out of busy. This helps
> > to avoid unnecessary periodic wakeups and thus save some power.
> >
> > Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
> > ---
> > fs/f2fs/segment.c | 8 +++++++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> > index 8bcbb50..df14030 100644
> > --- a/fs/f2fs/segment.c
> > +++ b/fs/f2fs/segment.c
> > @@ -1379,6 +1379,8 @@ static int issue_discard_thread(void *data)
> > struct discard_policy dpolicy;
> > unsigned int wait_ms = DEF_MIN_DISCARD_ISSUE_TIME;
> > int issued;
> > + unsigned long interval = sbi->interval_time[REQ_TIME] * HZ;
> > + long delta;
> >
> > set_freezable();
> >
> > @@ -1410,7 +1412,11 @@ static int issue_discard_thread(void *data)
> > __wait_all_discard_cmd(sbi, &dpolicy);
> > wait_ms = dpolicy.min_interval;
> > } else if (issued == -1){
> > - wait_ms = dpolicy.mid_interval;
> > + delta = (sbi->last_time[REQ_TIME] + interval) - jiffies;
>
> I agree that we need to consider power consumption. One more consideration is
> that discard thread may need different submission frequency comparing to garbage
> collection thread, maybe a little fast, would it be better to split
> sbi->interval_time[REQ_TIME] according to gc/discard type.
>
> How do you think?
>
> Thanks,
>
Thanks for the review.
You mean when GC type is urgent? I see that for that case, the discard policy is
changed to DPOLICY_FORCE, which sets dpolicy->io_aware as false and hence,
cannot fall into this (issued == -1) case at all.
> > + if (delta > 0)
> > + wait_ms = jiffies_to_msecs(delta);
> > + else
> > + wait_ms = dpolicy.mid_interval;
> > } else {
> > wait_ms = dpolicy.max_interval;
> > }
> >
--
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
WARNING: multiple messages have this Message-ID (diff)
From: Sahitya Tummala <stummala@codeaurora.org>
To: Chao Yu <chao@kernel.org>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <yuchao0@huawei.com>,
linux-f2fs-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [f2fs-dev] [PATCH] f2fs: fix unnecessary periodic wakeup of discard thread when dev is busy
Date: Sun, 2 Sep 2018 16:04:11 +0530 [thread overview]
Message-ID: <20180902103411.GE12489@codeaurora.org> (raw)
In-Reply-To: <ae0ec622-1fd3-d28a-019b-75a507e551f6@kernel.org>
On Sun, Sep 02, 2018 at 04:52:40PM +0800, Chao Yu wrote:
> On 2018/8/31 17:39, Sahitya Tummala wrote:
> > When dev is busy, discard thread wake up timeout can be aligned with the
> > exact time that it needs to wait for dev to come out of busy. This helps
> > to avoid unnecessary periodic wakeups and thus save some power.
> >
> > Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
> > ---
> > fs/f2fs/segment.c | 8 +++++++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> > index 8bcbb50..df14030 100644
> > --- a/fs/f2fs/segment.c
> > +++ b/fs/f2fs/segment.c
> > @@ -1379,6 +1379,8 @@ static int issue_discard_thread(void *data)
> > struct discard_policy dpolicy;
> > unsigned int wait_ms = DEF_MIN_DISCARD_ISSUE_TIME;
> > int issued;
> > + unsigned long interval = sbi->interval_time[REQ_TIME] * HZ;
> > + long delta;
> >
> > set_freezable();
> >
> > @@ -1410,7 +1412,11 @@ static int issue_discard_thread(void *data)
> > __wait_all_discard_cmd(sbi, &dpolicy);
> > wait_ms = dpolicy.min_interval;
> > } else if (issued == -1){
> > - wait_ms = dpolicy.mid_interval;
> > + delta = (sbi->last_time[REQ_TIME] + interval) - jiffies;
>
> I agree that we need to consider power consumption. One more consideration is
> that discard thread may need different submission frequency comparing to garbage
> collection thread, maybe a little fast, would it be better to split
> sbi->interval_time[REQ_TIME] according to gc/discard type.
>
> How do you think?
>
> Thanks,
>
Thanks for the review.
You mean when GC type is urgent? I see that for that case, the discard policy is
changed to DPOLICY_FORCE, which sets dpolicy->io_aware as false and hence,
cannot fall into this (issued == -1) case at all.
> > + if (delta > 0)
> > + wait_ms = jiffies_to_msecs(delta);
> > + else
> > + wait_ms = dpolicy.mid_interval;
> > } else {
> > wait_ms = dpolicy.max_interval;
> > }
> >
--
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
next prev parent reply other threads:[~2018-09-02 10:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-31 9:39 [PATCH] f2fs: fix unnecessary periodic wakeup of discard thread when dev is busy Sahitya Tummala
2018-09-02 8:52 ` [f2fs-dev] " Chao Yu
2018-09-02 10:34 ` Sahitya Tummala [this message]
2018-09-02 10:34 ` Sahitya Tummala
2018-09-02 12:56 ` 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=20180902103411.GE12489@codeaurora.org \
--to=stummala@codeaurora.org \
--cc=chao@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--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 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.