public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Liu Bo <bo.liu@linux.alibaba.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org
Subject: Re: [PATCH] Block: initialize bio_cnt_ret_time for the first time
Date: Fri, 29 Jun 2018 14:41:56 -0700	[thread overview]
Message-ID: <20180629214156.3dasxt5t4cvfnxan@US-160370MP2.local> (raw)
In-Reply-To: <c68e7055-4f0c-9910-c924-7006ec67789c@kernel.dk>

On Fri, Jun 29, 2018 at 02:46:27PM -0600, Jens Axboe wrote:
> On 6/29/18 2:43 PM, Liu Bo wrote:
> > On Fri, Jun 29, 2018 at 02:26:07PM -0600, Jens Axboe wrote:
> >> On 6/29/18 2:23 PM, Liu Bo wrote:
> >>> On Fri, Jun 29, 2018 at 02:00:01PM -0600, Jens Axboe wrote:
> >>>> On 6/20/18 9:07 PM, Liu Bo wrote:
> >>>>> When a new tg is created, tg->bio_cnt_ret_time is 0, so if the first
> >>>>> IO going thru this tg turns out to be a bad one, we fail to record it
> >>>>> in tg->bad_bio_cnt as
> >>>>>
> >>>>> if (jiffies > bio_cnt_ret_time) {
> >>>>> 	tg->bad_bio_cnt /= 2;
> >>>>> }
> >>>>
> >>>> Shouldn't we rather ensure that ->bio_cnt_ret_time is initialized to
> >>>> jiffies?
> >>>>
> >>>
> >>> Indeed, it's what the patch does, i.e. initialize tg->bio_cnt_reset_time to
> >>> jiffies on the first use.
> >>
> >> You do it on the first use, on the hot path, presumable. My suggestion
> >> was to do it when tg is instantiated instead. From a quick look, that
> >> would appear to be in throtl_pd_alloc().
> >>
> > 
> > Doing it when tg is instantiated would end up with the same problem.
> > 
> > 1) tg is instantiated, tg->bio_cnt_reset_time is set to jiffies.
> > (after a few jiffies...)
> > 2) the 1st IO gets dispatched and reaches endio.
> >   2.1) tg->bad_bio_cnt++ #if the IO's latency > threshold.
> >   2.2) if (jiffies > bio_cnt_reset_time)
> > 
> > At 2.2), (the jiffies at this point > tg->bio_cnt_reset_time).  If
> > this IO is a bad one, then tg->bad_bio_cnt would become 0 instead of 1
> > since we do tg->bad_bio_cnt /= 2 in the if statement.
> 
> That's kind of an ugly way to use it. How is it any different from when
> the tg has been idle for a while? There shouldn't be a need to special
> case this.

Yes, we can leave this corner case alone.

thanks,
-liubo

      reply	other threads:[~2018-06-29 21:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-21  3:07 [PATCH] Block: initialize bio_cnt_ret_time for the first time Liu Bo
2018-06-29 19:50 ` Liu Bo
2018-06-29 20:00 ` Jens Axboe
2018-06-29 20:23   ` Liu Bo
2018-06-29 20:26     ` Jens Axboe
2018-06-29 20:43       ` Liu Bo
2018-06-29 20:46         ` Jens Axboe
2018-06-29 21:41           ` Liu Bo [this message]

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=20180629214156.3dasxt5t4cvfnxan@US-160370MP2.local \
    --to=bo.liu@linux.alibaba.com \
    --cc=axboe@kernel.dk \
    --cc=linux-block@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