mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Shaohua Li <shli@kernel.org>
To: Tejun Heo <tj@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>,
	linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH 1/2] blk-throtl: make latency= absolute
Date: Thu, 9 Nov 2017 20:27:13 -0800	[thread overview]
Message-ID: <20171110042713.quytcwbu6g6xwvpt@kernel.org> (raw)
In-Reply-To: <20171109234258.GD983427@devbig577.frc2.facebook.com>

On Thu, Nov 09, 2017 at 03:42:58PM -0800, Tejun Heo wrote:
> Hello, Shaohua.
> 
> On Thu, Nov 09, 2017 at 03:12:12PM -0800, Shaohua Li wrote:
> > The percentage latency makes sense, but the absolute latency doesn't to me. A
> > 4k IO latency could be much smaller than 1M IO latency. If we don't add
> > baseline latency, we can't specify a latency target which works for both 4k and
> > 1M IO.
> 
> It isn't adaptive for sure.  I think it's still useful for the
> following reasons.
> 
> 1. The absolute latency target is by nature both workload and device
>    dependent.  For a lot of use cases, coming up with a decent number
>    should be possible.
> 
> 2. There are many use cases which aren't sensitive to the level where
>    they care much about the different between small and large
>    requests.  e.g. protecting a managerial job so that it doesn't
>    completely stall doesn't require tuning things to that level.  A
>    value which is comfortably higher than usually expected latencies
>    would often be enough (say 100ms).
> 
> 3. It's also useful for verification / testing.

I think the absolute latency would only work for HD. For a SSD, a 4k latency
probably is 60us and 1M latency is 500us. The disk must be very contended to
make 4k latency reach 500us. Not sensitive doesn't mean no protection. If the
use case sets rough latency, say 1ms, there will be no protection for 4k IO at
all. The baseline latency is pretty reliable for SSD actually. So I'd rather
keeping the baseline latency for SSD but using absolute latency for HD, which
can be done easily by setting DFL_HD_BASELINE_LATENCY to 0.

Thanks,
Shaohua

  reply	other threads:[~2017-11-10  4:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-09 22:19 Tejun Heo
2017-11-09 22:20 ` [PATCH 2/2] blk-throtl: add relative percentage support to latency= Tejun Heo
2017-11-14 22:06   ` Shaohua Li
2017-11-09 23:12 ` [PATCH 1/2] blk-throtl: make latency= absolute Shaohua Li
2017-11-09 23:42   ` Tejun Heo
2017-11-10  4:27     ` Shaohua Li [this message]
2017-11-10 15:43       ` Tejun Heo
2017-11-13  4:29         ` Shaohua Li
2017-11-13 11:27           ` Tejun Heo
2017-11-13 14:18             ` Tejun Heo
2017-11-13 22:08               ` Shaohua Li
2017-11-14 14:52                 ` Tejun Heo

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=20171110042713.quytcwbu6g6xwvpt@kernel.org \
    --to=shli@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tj@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

all inboxes | Powered by JetHome®