On Tue, Aug 08, 2017 at 04:53:08PM +0200, Alberto Garcia wrote:
On Tue 08 Aug 2017 03:45:44 PM CEST, Manos Pitsidianakis wrote:
On Tue, Aug 08, 2017 at 03:13:36PM +0200, Alberto Garcia wrote:
On Mon 31 Jul 2017 11:54:41 AM CEST, Manos Pitsidianakis wrote:
block/throttle.c uses existing I/O throttle infrastructure inside a
block filter driver. I/O operations are intercepted in the filter's
read/write coroutines, and referred to block/throttle-groups.c

The driver can be used with the syntax
-drive driver=throttle,file.filename=foo.qcow2, \

Sorry for not having noticed this earlier, but can't you define the
throttling group (and its limits) using -object throttle-group ... as
shown in the previous patch, and simply reference it here? Or would we
have two alternative ways of setting the throttling limits?

What happens if you have many -drive lines each one with a different set
of limits but with the same throttling group?

The limits of the last one to be processed will win.

That's what the current throttling API does, and I tend to agree that
it's not completely straightforward (a few people have asked me the same
question since this feature is available).

If we're going to add a new API we could eliminate this ambiguity. After
all the previous -drive throttling.iops-total=... would still be
available, wouldn't it?

Indeed, it already is.

So basically if we have anonymous groups, we accept limits in the
driver options but only without a group-name.

In the commit message you do however have limits and a group name, is
that a mistake?

   -drive driver=throttle,file.filename=foo.qcow2, \

Sorry this wasn't clear, I'm actually proposing to remove limits from the throttle driver options and only create/config throttle groups via -object/object-add.

Attachment: signature.asc
Description: PGP signature

Reply via email to