Am 10.01.2013 um 11:45 schrieb Markus Armbruster <arm...@redhat.com>:
> Subject line made me go "huh?" until I realized that you mean "Guest
> locks up", not "QEMU uses locks to synchronize". Suggest to add the
> preposition :)
>
> Peter Lieven <p...@dlhnet.de> writes:
>
>> If io_limits are specified during runtime that exceed the number of
>> operations in flight
>> bs->io_base is not initialized in the else statement in
>> bdrv_exceed_io_limits().
>
> I'm confused.
>
> if ((bs->slice_start < now)
> && (bs->slice_end > now)) {
> bs->slice_end = now + bs->slice_time;
> } else {
> bs->slice_time = 5 * BLOCK_IO_SLICE_TIME;
> bs->slice_start = now;
> bs->slice_end = now + bs->slice_time;
>
> bs->io_base.bytes[is_write] = bs->nr_bytes[is_write];
> bs->io_base.bytes[!is_write] = bs->nr_bytes[!is_write];
>
> bs->io_base.ios[is_write] = bs->nr_ops[is_write];
> bs->io_base.ios[!is_write] = bs->nr_ops[!is_write];
> }
>
> It's set in the else. Could you explain what goes wrong in a bit more
> detail?
If io_limits are enabled while there are I/Os in flight, we do not enter
the else tree as bs->slice_start and bs->slice_end are initialized
in bdrv_io_limits_enable().
In bdrv_exceed_iops_limits() ios_base is then initialized as
ios_base = bs->nr_ops[is_write] - bs->io_base.ios[is_write];
ios_base is then a very high value if the machine runs for some time.
wait_time is then also a very high value as it is calculated as:
wait_time = (ios_base + 1) / iops_limit;
I hope my fix is correct. Maybe there is sth else wrong, but at least this
fixes the locking of the guest for me.
My intention is not to limit I/O in general, just watch it and shape guests
that behave inappropriate.
Peter
