On Wed, Jul 04, 2018 at 03:54:10PM +0100, Stefan Hajnoczi wrote: > Throttle groups consist of members sharing one throttling state > (including bps/iops limits). Round-robin scheduling is used to ensure > fairness. If a group member already has a timer pending then other > groups members do not schedule their own timers. The next group member > will have its turn when the existing timer expires. > > A hang may occur when a group member leaves while it had a timer > scheduled. Although the code carefully removes the group member from > the round-robin list, it does not schedule the next member. Therefore > remaining members continue to wait for the removed member's timer to > expire. > > This patch schedules the next request if a timer is pending. > Unfortunately the actual bug is a race condition that I've been unable > to capture in a test case. > > Sometimes drive2 hangs when drive1 is removed from the throttling group: > > $ qemu ... -drive > if=none,id=drive1,cache=none,format=qcow2,file=data1.qcow2,iops=100,group=foo > \ > -device virtio-blk-pci,id=virtio-blk-pci0,drive=drive1 \ > -drive > if=none,id=drive2,cache=none,format=qcow2,file=data2.qcow2,iops=10,group=foo \ > -device virtio-blk-pci,id=virtio-blk-pci1,drive=drive2 > (guest-console1)# fio -filename /dev/vda 4k-seq-read.job > (guest-console2)# fio -filename /dev/vdb 4k-seq-read.job > (qmp) {"execute": "block_set_io_throttle", "arguments": {"device": > "drive1","bps": 0,"bps_rd": 0,"bps_wr": 0,"iops": 0,"iops_rd": 0,"iops_wr": > 0}}
Hi Stefan, I realize you want to preserve the long lines to not break the JSON QMP command. But, FWIW, you might want to format it using one of the convenient websites: https://jsonformatter.org/ So your QMP command nicely wraps (for the 'cost' of 11 extra lines): { "execute": "block_set_io_throttle", "arguments": { "device": "drive1", "bps": 0, "bps_rd": 0, "bps_wr": 0, "iops": 0, "iops_rd": 0, "iops_wr": 0 } } [...] -- /kashyap