[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v8 10/14] migration: add postcopy migration of d
From: |
John Snow |
Subject: |
Re: [Qemu-devel] [PATCH v8 10/14] migration: add postcopy migration of dirty bitmaps |
Date: |
Thu, 16 Nov 2017 19:36:07 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
On 11/16/2017 05:24 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> + /* if a block is zero we need to flush here since the network
>>> + * bandwidth is now a lot higher than the storage device bandwidth.
>>> + * thus if we queue zero blocks we slow down the migration. */
>> Can you elaborate on this for me?
>
> it comes from migration/block.c, as it was a prototype for dirty bitmaps
> migration.
> May be the original thought was to give destination storage more time to
> handle
> write-zeros? It may make sense if it can't do it fast but really writes
> zeros.
>
>>
>>> + if (flags & DIRTY_BITMAP_MIG_FLAG_ZEROES) {
>>> + qemu_fflush(f);
>>> + } else {
>>> + qemu_put_be64(f, buf_size);
>>> + qemu_put_buffer(f, buf, buf_size);
>>> + }
>>> +
>>> + g_free(buf);
>>> +}
Peter, Stefan; do you have any insight on the reason for this blurb's
appearance in migration/block.c? Looks like it showed up in
323004a39d4d8d33c744a5b108f80bfe6402fca3
I'm not sure I understand what the concern was that lead to this, unless
it's simply that without a flush() we can't guarantee progress.