From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34754) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUiep-0003AK-IW for qemu-devel@nongnu.org; Wed, 16 May 2012 14:09:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SUiei-0000LL-Va for qemu-devel@nongnu.org; Wed, 16 May 2012 14:09:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58472) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUiei-0000Ka-Ml for qemu-devel@nongnu.org; Wed, 16 May 2012 14:09:00 -0400 Message-ID: <4FB3DB96.3000500@redhat.com> Date: Wed, 16 May 2012 19:53:42 +0300 From: Orit Wasserman MIME-Version: 1.0 References: <1337169582-28312-1-git-send-email-owasserm@redhat.com> <1337169582-28312-4-git-send-email-owasserm@redhat.com> <4FB3D5B9.8000604@redhat.com> In-Reply-To: <4FB3D5B9.8000604@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v10 3/9] Add XBZRLE documentation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: aliguori@us.ibm.com, quintela@redhat.com, stefanha@gmail.com, mdroth@linux.vnet.ibm.com, qemu-devel@nongnu.org, blauwirbel@gmail.com, avi@redhat.com, pbonzini@redhat.com 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 >> --- >> 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 >