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
