On Fri, Apr 7, 2017 at 9:30 AM, 858585 jemmy <jemmy858...@gmail.com> wrote:
> On Thu, Apr 6, 2017 at 10:02 PM, Stefan Hajnoczi <stefa...@redhat.com> wrote:
>> On Wed, Apr 05, 2017 at 05:27:58PM +0800, jemmy858...@gmail.com wrote:
>>> From: Lidong Chen <lidongc...@tencent.com>
>>>
>>> when migration with high speed, mig_save_device_bulk invoke
>>> bdrv_is_allocated too frequently, and cause vnc reponse slowly.
>>> this patch limit the time used for bdrv_is_allocated.
>>
>> bdrv_is_allocated() is supposed to yield back to the event loop if it
>> needs to block. If your VNC session is experiencing jitter then it's
>> probably because a system call in the bdrv_is_allocated() code path is
>> synchronous when it should be asynchronous.
>>
>> You could try to identify the system call using strace -f -T. In the
>> output you'll see the duration of each system call. I guess there is a
>> file I/O system call that is taking noticable amounts of time.
>
> yes, i find the reason where bdrv_is_allocated needs to block.
>
> the mainly reason is caused by qemu_co_mutex_lock invoked by
> qcow2_co_get_block_status.
> qemu_co_mutex_lock(&s->lock);
> ret = qcow2_get_cluster_offset(bs, sector_num << 9, &bytes,
> &cluster_offset);
> qemu_co_mutex_unlock(&s->lock);
>
> other reason is caused by l2_load invoked by
> qcow2_get_cluster_offset.
>
> /* load the l2 table in memory */
>
> ret = l2_load(bs, l2_offset, &l2_table);
> if (ret < 0) {
> return ret;
> }
>
>>
>> A proper solution is to refactor the synchronous code to make it
>> asynchronous. This might require invoking the system call from a
>> thread pool worker.
>>
>
> yes, i agree with you, but this is a big change.
> I will try to find how to optimize this code, maybe need a long time.
>
> this patch is not a perfect solution, but can alleviate the problem.
Hi everyone:
Do you think should we use this patch currently? and optimize this
code later?
Thanks.
>
>> Stefan
