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

[Avi Kivity <avi@redhat.com>]

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.

-- 
error compiling committee.c: too many arguments to function