From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41520) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZMUu-0004Yx-Fz for qemu-devel@nongnu.org; Wed, 22 Jun 2011 08:25:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QZMUt-0000d9-35 for qemu-devel@nongnu.org; Wed, 22 Jun 2011 08:25:32 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:43794) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZMUs-0000d5-R1 for qemu-devel@nongnu.org; Wed, 22 Jun 2011 08:25:30 -0400 Received: by yia25 with SMTP id 25so379054yia.4 for ; Wed, 22 Jun 2011 05:25:30 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4E01D9B3.8030002@codemonkey.ws> References: <4E01D9B3.8030002@codemonkey.ws> Date: Wed, 22 Jun 2011 13:25:30 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] XBRLE page delta compression for live migration of large memory apps List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Shribman, Aidan" Cc: "qemu-devel@nongnu.org" On Wed, Jun 22, 2011 at 1:01 PM, Anthony Liguori wr= ote: > On 05/22/2011 07:00 AM, Shribman, Aidan wrote: >> >> Subject: [PATCH] XBRLE page delta compression for live migration of larg= e >> memory apps >> From: Aidan Shribman >> >> By using XBRLE (Xor Based Run-Length-Encoding) we can reduce required >> bandwidth for transfering of dirty memory pages during live migration >> =A0 =A0 =A0 =A0 migrate_set_cachesize >> =A0 =A0 =A0 =A0 migrate -x >> Qemu host: Ubuntu 10.10 >> Testing: live migration (w and w/o XBRLE) tested successfully. > > By how much? > > This is a change to the live migration protocol, it would also require > documentation and an understanding of how it affects compatibility. > > The patch really needs to be split into logical pieces too. =A0It's a bit= too > big for a meaningful review. Two places where you could consider splitting the patch is the caching and the sampling. Are they necessary for correctness and could they be submitted as follow-up patches to a core patch which does just the XBRLE? Also, whenever there are heuristics and use of floating point then there is some magic going on. It may be necessary and give a huge performance boost but needs explanation so it is not a black box or fragile mechanism once it has been merged upstream. Stefan