From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59293) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqQFM-00012f-BH for qemu-devel@nongnu.org; Mon, 08 Aug 2011 09:52:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QqQFI-0001iD-Ch for qemu-devel@nongnu.org; Mon, 08 Aug 2011 09:52:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14522) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqQFI-0001i8-0t for qemu-devel@nongnu.org; Mon, 08 Aug 2011 09:51:56 -0400 Message-ID: <4E3FE9F0.9070702@redhat.com> Date: Mon, 08 Aug 2011 16:51:44 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E3FE4CF.4060108@codemonkey.ws> In-Reply-To: <4E3FE4CF.4060108@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4] XBZRLE delta for live migration of large memory apps List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Stefan Hajnoczi , Dor Laor , qemu-devel Developers , libvirt-list@redhat.com, Blue Swirl , "Shribman, Aidan" On 08/08/2011 04:29 PM, Anthony Liguori wrote: > > One thing that strikes me about this algorithm is that it's very good > for a particular type of workload--shockingly good really. Poking bytes at random places in memory is fairly generic. If you have a lot of small objects, and modify a subset of them, this is the pattern you get. > > I think workload aware migration compression is possible for a lot of > different types of workloads. That makes me a bit wary of QEMU > growing quite a lot of compression mechanisms. > > It makes me think that this logic may really belong at a higher level > where more information is known about the workload. For instance, I > can imagine XBZRLE living in something like libvirt. A better model would be plugin based. -- error compiling committee.c: too many arguments to function