Re: [Qemu-devel] [PATCH 4/5] disk_deadlines: add control of requests time expiration

["Denis V. Lunev" <den@openvz.org>]

On 09/08/2015 02:06 PM, Kevin Wolf wrote:
> Am 08.09.2015 um 10:00 hat Denis V. Lunev geschrieben:
>> From: Raushaniya Maksudova <rmaksudova@virtuozzo.com>
>>
>> If disk-deadlines option is enabled for a drive, one controls time
>> completion of this drive's requests. The method is as follows (further
>> assume that this option is enabled).
>>
>> Every drive has its own red-black tree for keeping its requests.
>> Expiration time of the request is a key, cookie (as id of request) is an
>> appropriate node. Assume that every requests has 8 seconds to be completed.
>> If request was not accomplished in time for some reasons (server crash or
>> smth else), timer of this drive is fired and an appropriate callback
>> requests to stop Virtial Machine (VM).
>>
>> VM remains stopped until all requests from the disk which caused VM's
>> stopping are completed. Furthermore, if there is another disks whose
>> requests are waiting to be completed, do not start VM : wait completion
>> of all "late" requests from all disks.
>>
>> Signed-off-by: Raushaniya Maksudova <rmaksudova@virtuozzo.com>
>> Signed-off-by: Denis V. Lunev <den@openvz.org>
>> CC: Stefan Hajnoczi <stefanha@redhat.com>
>> CC: Kevin Wolf <kwolf@redhat.com>
>> +    disk_deadlines->expired_tree = true;
>> +    need_vmstop = !atomic_fetch_inc(&num_requests_vmstopped);
>> +    pthread_mutex_unlock(&disk_deadlines->mtx_tree);
>> +
>> +    if (need_vmstop) {
>> +        qemu_system_vmstop_request_prepare();
>> +        qemu_system_vmstop_request(RUN_STATE_PAUSED);
>> +    }
>> +}
> What behaviour does this result in? If I understand correctly, this is
> an indirect call of do_vm_stop(), which involves a bdrv_drain_all(). In
> this case, qemu would completely block (including unresponsive monitor)
> until the request can complete.
>
> Is this what you are seeing with this patch, or why doesn't the
> bdrv_drain_all() call cause such effects?
>
> Kevin
interesting point. Yes, it flushes all requests and most likely
hangs inside waiting requests to complete. But fortunately
this happens after the switch to paused state thus
the guest becomes paused. That's why I have missed this
fact.

This (could) be considered as a problem but I have no (good)
solution at the moment. Should think a bit on.

Nice catch, though!

Den