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 <owass...@redhat.com>
>> ---
>> 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
>
