qemu-devel
[Top][All Lists]
Advanced

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

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


From: Shribman, Aidan
Subject: Re: [Qemu-devel] [PATCH v4] XBZRLE delta for live migration of large memory apps
Date: Wed, 10 Aug 2011 17:07:24 +0200

-----Original Message-----
From: Anthony Liguori [mailto:address@hidden 
Sent: Monday, August 08, 2011 7:56 PM
To: Avi Kivity
Cc: Blue Swirl; Stefan Hajnoczi; Shribman, Aidan; qemu-devel Developers
Subject: Re: [Qemu-devel] [PATCH v4] XBZRLE delta for live migration of large 
memory apps

On 08/08/2011 11:53 AM, Avi Kivity wrote:
> On 08/08/2011 07:19 PM, Anthony Liguori wrote:
>>
>>> Real feature negotiation will likely have to wait until the next version
>>> of the migration protocol.
>>
>> Since we're talking about moving to ASN.1 for 1.0, I think we should
>> think also include memory compression and wait until we rev the
>> protocol before introducing any type of compression.
>
> Is anyone actually working on this?

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.

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.

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?

Aidan




reply via email to

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