Re: [Qemu-devel] [PATCH] migration: not send zero page header in ram bulk stage

[Hailiang Zhang <zhang.zhanghailiang@huawei.com>]

Hi,

On 2016/1/15 18:24, Li, Liang Z wrote:
>> It seems that this patch is incorrect, if the no-zero pages are zeroed again
>> during !ram_bulk_stage, we didn't send the new zeroed page, there will be
>> an error.
>>
>
> If not in ram_bulk_stage, still send the header, could you explain why it's wrong?
>
> Liang
>

I have made a mistake, and yes, this patch can speed up the live migration time,
especially when there are many zero pages, it will be more obvious.
I like this idea. Did you test it with postcopy ? Does it break postcopy ?

Thanks,
zhanghailiang

>>> For guest just uses a small portions of RAM, this change can avoid
>>> allocating all the guest's RAM pages in the destination node after
>>> live migration. Another benefit is destination QEMU can save lots of
>>> CPU cycles for zero page checking.
>>>
>>> Signed-off-by: Liang Li <liang.z.li@intel.com>
>>> ---
>>>    migration/ram.c | 10 ++++++----
>>>    1 file changed, 6 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/migration/ram.c b/migration/ram.c index 4e606ab..c4821d1
>>> 100644
>>> --- a/migration/ram.c
>>> +++ b/migration/ram.c
>>> @@ -705,10 +705,12 @@ static int save_zero_page(QEMUFile *f,
>> RAMBlock
>>> *block, ram_addr_t offset,
>>>
>>>        if (is_zero_range(p, TARGET_PAGE_SIZE)) {
>>>            acct_info.dup_pages++;
>>> -        *bytes_transferred += save_page_header(f, block,
>>> -                                               offset | RAM_SAVE_FLAG_COMPRESS);
>>> -        qemu_put_byte(f, 0);
>>> -        *bytes_transferred += 1;
>>> +        if (!ram_bulk_stage) {
>>> +            *bytes_transferred += save_page_header(f, block, offset |
>>> +                                                   RAM_SAVE_FLAG_COMPRESS);
>>> +            qemu_put_byte(f, 0);
>>> +            *bytes_transferred += 1;
>>> +        }
>>>            pages = 1;
>>>        }
>>>
>>>
>>
>>
>
>
> .
>