qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [v2 2/2] migration: Implement multiple compression thre


From: Zhang, Yang Z
Subject: Re: [Qemu-devel] [v2 2/2] migration: Implement multiple compression threads
Date: Fri, 21 Nov 2014 06:18:06 +0000

Eric Blake wrote on 2014-11-06:

Hi Eric

Thanks for your review and comment.

> On 11/06/2014 12:08 PM, Li Liang wrote:
>> Instead of sending the guest memory directly, this solution compress 
>> the ram page before sending, after receiving, the data will be 
>> decompressed.
>> This feature can help to reduce the data transferred about 60%, this 
>> is very useful when the network bandwidth is limited, and the 
>> migration time can also be reduced about 70%. The feature is off by 
>> default, following the document docs/multiple-compression-threads.txt
>> for information to use it.
>> 
>> Reviewed-by: Eric Blake <address@hidden>
> 
> Please DON'T add this line unless the author spelled it out (or if 
> they mentioned that it would be okay if you fix minor issues).  I 
> intentionally omitted a reviewed-by on v1:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2014-11/msg00672.html
> 
> because I was not happy with the patch as it was presented and did not 
> think the work to fix it was trivial.  Furthermore, my review of v1 
> was just over the interface, and not the entire patch; there are very 
> likely still bugs lurking in the .c files.  Once again, I'm going to 
> limit my review of v2 to the interface (at least in this email):
> 
>> Signed-off-by: Li Liang <address@hidden>
>> ---
>> 
>> +++ b/qapi-schema.json
>> @@ -491,13 +491,17 @@
>>  #          to enable the capability on the source VM. The feature is
>>  disabled by #          default. (since 1.6) #
>> +# @compress: Using the multiple compression threads to accelerate
>> +live migration. +#          This feature can help to reduce the
>> migration traffic, by sending +#          compressed pages. The feature
>> is disabled by default. (since 2.3) +#  # @auto-converge: If enabled, 
>> QEMU will automatically throttle down the
> guest
>>  #          to speed up convergence of RAM migration. (since 1.6)
>>  #
>>  # Since: 1.2
>>  ##
>>  { 'enum': 'MigrationCapability',
>> -  'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks'] 
>> }
>> +  'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks', 
>> + 'compress'] }
>> 
> 
> I'll repeat what I said on v1 (but this time, with some links to back 
> it up :)

Agree. Additional commands lead to complexity. 

> 
> We really need to avoid a proliferation of new commands, two per 
> tunable does not scale well.  I think now is the time to implement my 
> earlier suggestion at making MigrationCapability become THE resource for 
> tunables:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg02274.html

I see that you said you are trying to clean up this part. Have you done it? It 
is helpful if you can provide some draft patches or help on this since you are 
more professional than us on this part.

Best regards,
Yang



reply via email to

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