[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3] migration/block:limit the time used for bloc

From: 858585 jemmy
Subject: Re: [Qemu-devel] [PATCH v3] migration/block:limit the time used for block migration
Date: Fri, 7 Apr 2017 16:26:58 +0800

On Fri, Apr 7, 2017 at 9:30 AM, 858585 jemmy <address@hidden> wrote:
> On Thu, Apr 6, 2017 at 10:02 PM, Stefan Hajnoczi <address@hidden> wrote:
>> On Wed, Apr 05, 2017 at 05:27:58PM +0800, address@hidden wrote:
>>> From: Lidong Chen <address@hidden>
>>> 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?

>> Stefan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]