qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v10 3/9] Add XBZRLE documentation


From: Orit Wasserman
Subject: Re: [Qemu-devel] [PATCH v10 3/9] Add XBZRLE documentation
Date: Wed, 16 May 2012 19:53:42 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

On 05/16/2012 07:28 PM, Eric Blake wrote:
> On 05/16/2012 05:59 AM, Orit Wasserman wrote:
>> Signed-off-by: Orit Wasserman <address@hidden>
>> ---
>>  docs/xbzrle.txt |   97 
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 files changed, 97 insertions(+), 0 deletions(-)
>>  create mode 100644 docs/xbzrle.txt
>>
>> diff --git a/docs/xbzrle.txt b/docs/xbzrle.txt
>> new file mode 100644
>> index 0000000..aafdb84
>> --- /dev/null
>> +++ b/docs/xbzrle.txt
>> @@ -0,0 +1,97 @@
>> +XBZRLE (Xor Based Zero Run Length Encoding)
>> +===========================================
>> +
>> +Using XBZRLE (Xor Based Zero Run Length Encoding) allows for the reduction 
>> of VM downtime
>> +and the total live-migration time of Virtual machines. It is particularly 
>> useful for virtual machines running memory write intensive workloads that 
>> are typical of large enterprise applications such as SAP ERP Systems, and 
>> generally
> 
> Any reason you aren't wrapping at column 80?
I will fix it.
> 
>> +speaking for any application that uses a sparse memory update pattern.
>> +
>> +Instead of sending the changed guest memory page this solution will send a 
>> compressed version of the updates, thus reducing the amount of data sent 
>> during live migration.
>> +In order to be able to calculate the update, the previous memory pages 
>> needed to be stored. Those pages are stored in a dedicated cache (hash 
>> table) and are accessed by their address.
>> +The larger the cache size the better the chances are that the page has 
>> already been stored in the cache. A Small cache size will result in high 
>> cache miss rate.
> 
> s/Small/small/
> 
>> +Usage
>> +======
>> +
>> +1. Activate xbzrle
>> +2. Set the XBZRLE cache size - the cache size is in MBytes and should be a 
>> power of 2. The cache default value is 64MBytes.
>> +3. start outgoing migration
>> +
>> +A typical usage scenario:
>> +    {qemu} migrate_set_parameter xbzrle
>> +    {qemu} migrate_set_cachesize 256m
>> +    {qemu} migrate -d tcp:destination.host:4444
>> +    {qemu} info migrate
>> +    ...
>> +    transferred ram-duplicate: A kbytes
>> +    transferred ram-normal: B kbytes
>> +    transferred ram-xbrle: C kbytes
>> +    overflow ram-xbrle: D pages
>> +    cache-miss ram-xbrle: E pages
>> +
>> +cache-miss: the number of cache misses to date - high cache-miss rate
>> +indicates that the cache size is set too low.
>> +overflow: the number of overflows in the decoding which where the delta 
>> could not be compressed. This can happen if the changes in the pages are too 
>> large
>> +or there are many short changes for example change every second byte (half 
>> a page).
> 
> Can cachesize be modified during an in-progress migration?  Do both
> source and destination need to agree on cache size?
Yes, you can resize the cache  during ongoing migration.
Only the source QEMU uses the cache.

Orit
> 




reply via email to

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