Re: [Qemu-devel] [PATCH v4] XBZRLE delta for live migration of large memory apps

[Anthony Liguori <anthony@codemonkey.ws>]

On 08/10/2011 10:12 AM, Avi Kivity wrote:
> On 08/10/2011 06:07 PM, Shribman, Aidan wrote:
>> XBZRLE will very rarely (if at all) degrade live-migration as it runs
>> at ~2 GB/s or 16 Gbps. Additionally XBZRLE could get even faster by
>> using 128bit registers instead of the 64bit registers used currently.
>> IMO XBZRLE could safely be used by default exposing capabilities by
>> Qemu such that higher level management would handle static negotiation
>> (as suggested).
>>
>> Given that XBZRLE will seldom fail due to inflated encoded output (an
>> example for such a case -> dirty the new page every 2nd 64bit word:
>> the word-wise Xor would give 0x0y0z... ZRLE would future encode as
>> 01x01y01z... a +50% increase), I see little incentive in automatic
>> XBZRLE disablement.
>
> My concern is not reduced migration bandwidth or inflated image size,
> but increased cpu use for copying pages to the cache and xoring them.
>
>> As to implementing XBZRLE delta compression as a compression plug-in -
>> this is not that straight forward as it has some interesting interplay
>> with DUP packat's which are crucial for performance, specifically a
>> page consisting of only zero's is LRU cached as reference without the
>> standard qemu_malloc()/memcpy() done in other cases. This is
>> especially important for eliminating slowdown during live-migration
>> initiation.
>
> I agree, it should be on-by-default and in the main code base. Please
> provide numbers to justify this on non-artificial workloads, and on
> artificial worst-case workloads.
>
>> As to waiting for ASN.1 capability - I can see this will make parsing
>> of live-migration messages much more reliable (ensuring that Qemu is
>> able to detect an incorrect protocol version) but I can't say I am
>> very happy waiting for 1.0 - are there any alternatives?
>>
>
> I don't think we should couple the two features together.

ASN.1 is orthogonal to capabilities.

Capabilities are a hard requirement before merging any new type of 
compression algorithm IMO.

Regards,

Anthony Liguori

>