All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alberto Garcia <berto@igalia.com>
To: Peter Lieven <pl@kamp.de>, Kevin Wolf <kwolf@redhat.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	qemu block <qemu-block@nongnu.org>
Subject: Re: block/throttle and burst bucket
Date: Mon, 08 Mar 2021 13:20:55 +0100	[thread overview]
Message-ID: <w51czw925w8.fsf@maestria.local.igalia.com> (raw)
In-Reply-To: <a56688da-d433-8405-cec5-3298d4edd91b@kamp.de>

On Mon 01 Mar 2021 01:11:55 PM CET, Peter Lieven <pl@kamp.de> wrote:
> Why we talk about throttling I still do not understand the following part in util/throttle.c function throttle_compute_wait
>
>
>     if (!bkt->max) {
>         /* If bkt->max is 0 we still want to allow short bursts of I/O
>          * from the guest, otherwise every other request will be throttled
>          * and performance will suffer considerably. */
>         bucket_size = (double) bkt->avg / 10;
>         burst_bucket_size = 0;
>     } else {
>         /* If we have a burst limit then we have to wait until all I/O
>          * at burst rate has finished before throttling to bkt->avg */
>         bucket_size = bkt->max * bkt->burst_length;
>         burst_bucket_size = (double) bkt->max / 10;
>     }
>
>
> Why burst_bucket_size = bkt->max / 10?
>
> From what I understand it should be bkt->max. Otherwise we compare the
> "extra" against a tenth of the bucket capacity

1) bkt->max is the burst rate in bytes/second [*]
2) burst_bucket_size is used to decide when to start throttling (you can
   see the code at the end of throttle_compute_wait()).

The important thing is that burst_bucket_size does not actually have an
influence on the actual burst rate. Increasing that value is not going
to make the I/O faster, it just means that I/O will be throttled later.

Once the I/O is throttled, the actual burst rate is define by how quick
the burst bucket leaks (see throttle_leak_bucket()).

The higher burst_bucket_size is, the longer we allow the guest to exceed
the maximum rate. So we divide blk->max by 10 in order to allow the
guest to perform 100ms' worth of I/O without being throttled.

See the commit message of 0770a7a6466cc2dbf4ac91841173ad4488e1fbc7 for
more details.

Berto


      reply	other threads:[~2021-03-08 12:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-25 17:34 block/throttle and burst bucket Peter Lieven
2021-02-26  9:27 ` Alberto Garcia
2021-02-26 12:33   ` Peter Lieven
2021-03-01 10:59     ` Kevin Wolf
2021-03-01 12:11       ` Peter Lieven
2021-03-08 12:20         ` Alberto Garcia [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=w51czw925w8.fsf@maestria.local.igalia.com \
    --to=berto@igalia.com \
    --cc=kwolf@redhat.com \
    --cc=pl@kamp.de \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.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.