[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH] qemu-options: explain disk I/O throttling optio
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-block] [PATCH] qemu-options: explain disk I/O throttling options |
Date: |
Wed, 22 Feb 2017 11:14:33 +0000 |
User-agent: |
Mutt/1.7.1 (2016-10-04) |
On Tue, Feb 21, 2017 at 11:58:00AM +0100, Alberto Garcia wrote:
> On Mon 20 Feb 2017 05:52:04 PM CET, Stefan Hajnoczi wrote:
> > The disk I/O throttling options have been listed for a long time but
> > never explained on the QEMU man page.
>
> > address@hidden address@hidden,address@hidden,address@hidden
> > +Specify bandwidth throttling limits in bytes per second, either for all
> > request
> > +types or for reads or writes only.
>
> Perhaps for the manual page it makes sense to use them, but bps, bps_rd,
> etc. are the legacy names for those options. They're internally renamed
> to throttling.bps-total, throttling.bps-read, ...
I used the parameter names already listed in the -drive documentation.
We need to keep the legacy names but I will add another patch that
documents the new names and encourages using them.
> > Values must be larger than the maximum
> > +request size to avoid timeouts or hangs in the guest. At minimum use 2
> > MB/s
> > +for disks.
>
> Is this so? throttle_compute_wait() does not use the request size at
> all. The size is used to do the accounting afterwards. In other words:
> requests are not throttled if they exceed the limit, they are throttled
> after the limit has been exceeded by previous requests.
>
> A low limit will certainly slow down the guest and can cause
> timeouts, but I don't know if being larger or smaller than the maximum
> request size is what makes the difference.
You are right, I'm still have the behavior of the old throttling
implementation in mind.
I'd still like to recommend a sane minimum because anything around the
size of a single request leads to timeouts and hangs inside the guest.
How about:
Small values can lead to timeouts or hangs inside the guest. A safe
minimum for disks is 2 MB/s.
> > address@hidden address@hidden,address@hidden,address@hidden
> > +Specify bursts in bytes per second, either for all request types or for
> > reads
> > +or writes only. Bursts allow the guest I/O to spike above the limit
> > +temporarily. The default burst value is 1/10th of the limit.
>
> "The default burst value is 1/10th of the limit" is an implementation
> detail that the user doesn't need to know about. What it means is that a
> bps limit of 10 MB/s is implemented internally as 1MB per 100ms.
>
> I would leave that out, it doesn't even make sense that the burst limit
> is lower than the normal limit, we actually forbid that (aaa1e77ffae52).
Unfortunately the bps_max = avg / 10 default value is visible via
query-block. A bug was recently reported about this:
https://bugzilla.redhat.com/show_bug.cgi?id=1414630
Would you prefer a private field in the throttling code so this detail
is hidden from users?
> > address@hidden address@hidden,address@hidden,address@hidden
> > +Specify request rate limits in requests per second, either for all request
> > +types or for reads or writes only.
>
> > address@hidden address@hidden,address@hidden,address@hidden
>
> You meant iops_max, iops_rd_max and iops_wr_max here?
Yes, thanks! Will fix in v2.
Stefan
signature.asc
Description: PGP signature