linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Hong zhi guo <honkiko@gmail.com>
Cc: Jens Axboe <axboe@kernel.dk>,
	cgroups@vger.kernel.org, Tejun Heo <tj@kernel.org>,
	linux-kernel@vger.kernel.org,
	Hong Zhiguo <zhiguohong@tencent.com>
Subject: Re: [PATCH v2] blk-throttle: simplify logic by token bucket algorithm
Date: Wed, 16 Oct 2013 10:14:06 -0400	[thread overview]
Message-ID: <20131016141405.GE17611@redhat.com> (raw)
In-Reply-To: <CAA7+ByWjdYTi5uXT6apLYkON1RnrFEGjHU318OD1VMen2YHKOA@mail.gmail.com>

On Wed, Oct 16, 2013 at 02:09:40PM +0800, Hong zhi guo wrote:
> Hi, Vivek,
> 
> Thanks for your careful review. I'll rename t_c to last_dispatch, it's
> much better.
> 
> For the big burst issue, I've different opinion. Let's discuss it.
> 
> Any time a big IO means a big burst. Even if it's throttled at first
> time, queued in
> the service_queue, and then waited for a while, when it's delivered
> out, it IS still
> a big burst. So throttling the bio for another while makes no sense.

If a malicious application is creating a big BIO and sending it out, then
effective IO rate as seen by application will be much higher than
throttling limit.

So yes, a burst is anyway going to happen when big IO is dispatched
to disk, but the question is when should that burst be allowed. What's
the effective IO rate application should see.
 
> 
> If a group has been idle for 5 minutes, then it owns the credit to
> deliver a big IO
> (within 300 * bps bytes). And the extra credit will be cut off after
> the delivery.

I think there are couple of issues here.

- First of all, if you think that a group is entitiled for tokens even
  when it is not doing IO, then why are you truncating the tokens after
  dispatch of a BIO.

- Second in general it does not seem right that a group is entitiled to
  tokens even when no IO is happening or group is not backlogged. That
  would mean a group will not do IO for 10 hours and then be entitiled
  to those tokens suddenly after 10 hours with a huge burst.

So I think you also agree that a group should not be entitiled to
tokens when group is not backlogged and that's why you seem to be
truncating extra tokens after dispatch of a BIO. If that's the case,
then even for first BIO, ideally a group should not be given tokens
for idle time.

Just think that an application has a huge BIO, say size 2MB. And group
has limit of say 8KB per second. Now if group has been idling long enough,
this BIO will be dispatched immediately. And effective rate a group
will be is much higher than 8KB/s. Which is not right, IMO.

If you argue that token entitilement for idle groups is not right and
doing it for first BIO in a batch is exception for simplicity reasons,
that still might be fine. But right now that does not seem to be the
case.

Thanks
Vivek

  reply	other threads:[~2013-10-16 14:14 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1381574794-7639-1-git-send-email-zhiguohong@tencent.com>
2013-10-14  9:09 ` [PATCH v2] blk-throttle: simplify logic by token bucket algorithm Hong Zhiguo
2013-10-14 13:36   ` Tejun Heo
2013-10-14 13:47     ` Hong zhi guo
2013-10-14 13:53     ` Hong zhi guo
2013-10-14 13:59       ` Tejun Heo
2013-10-15 12:35         ` Hong zhi guo
2013-10-15 16:19           ` Jens Axboe
2013-10-15 13:03     ` Vivek Goyal
2013-10-15 17:32   ` Vivek Goyal
2013-10-16  6:09     ` Hong zhi guo
2013-10-16 14:14       ` Vivek Goyal [this message]
2013-10-16 15:47         ` Hong zhi guo
2013-10-16 15:53         ` Tejun Heo
2013-10-16 16:22           ` Vivek Goyal
2013-10-17 12:17 ` [PATCH v3] " Hong Zhiguo
2013-10-18 15:55   ` Vivek Goyal
2013-10-20 12:08     ` Hong zhi guo
2013-10-20 12:11     ` [PATCH v4 0/2] " Hong Zhiguo
2013-10-20 12:11       ` [PATCH v4 1/2] " Hong Zhiguo
2014-04-10 10:07         ` Hong zhi guo
2014-04-10 13:32           ` Vivek Goyal
2013-10-20 12:11       ` [PATCH v4 2/2] blk-throttle: trim tokens generated for an idle tree Hong Zhiguo
2013-10-22 21:02         ` Vivek Goyal
2013-10-23  3:30           ` Hong zhi guo
2013-10-28  5:08           ` Hong zhi guo

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=20131016141405.GE17611@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=cgroups@vger.kernel.org \
    --cc=honkiko@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tj@kernel.org \
    --cc=zhiguohong@tencent.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;
as well as URLs for NNTP newsgroup(s).