qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]