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.