[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Throttling groups vs filter nodes
From: |
Alberto Garcia |
Subject: |
Re: [Qemu-devel] Throttling groups vs filter nodes |
Date: |
Mon, 29 May 2017 17:05:17 +0200 |
User-agent: |
Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu) |
On Sat 27 May 2017 09:56:03 AM CEST, Stefan Hajnoczi wrote:
> A quirk in the current implementation is that the throttling limits
> for the group are overwritten by each -drive throttling.group=group0.
> Limits for all but the last -drive in a group are ignored.
>
> There is no way to associate with an existing throttling group while
> keeping current limits in place. The caller must pass in desired
> limits with at least the last -drive (and with every hotplugged
> drive).
I actually just realized that passing throttling.group=group0 but no
actual limits is allowed but does nothing.
> The new throttling filter node could do things differently: If *no*
> limits were specified (i.e. iops, bps, etc) then keep existing limits
> for the group in place.
Yes, that sounds good to me. The problem here is block_set_io_throttle
(the QMP command), becuase the bps / iops parameters are mandatory, and
setting them to 0 disables the I/O limits for that device.
We can of course make them optional and if all limits are unset then we
can add a device to a throttling group. I'm not sure if that would make
the command a bit too complicated, as there are already different ways
to use it:
- bps or iops != 0 -> set the I/O limits of a throttling group. The
selected device is moved to that group if it
wasn't there yet.
- bps and iops == 0 -> remove a device from a throttling group
without touching that group's I/O limits.
and a new one would be:
- bps and iops unset -> add a device to a throttling group, without
touching that group's I/O limits.
Berto