From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33565) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqQzd-00009B-B1 for qemu-devel@nongnu.org; Mon, 08 Aug 2011 10:39:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QqQzY-0002x3-TS for qemu-devel@nongnu.org; Mon, 08 Aug 2011 10:39:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60735) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqQzY-0002wQ-EC for qemu-devel@nongnu.org; Mon, 08 Aug 2011 10:39:44 -0400 Message-ID: <4E3FF524.7070509@redhat.com> Date: Mon, 08 Aug 2011 17:39:32 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E3FE4CF.4060108@codemonkey.ws> <4E3FE9F0.9070702@redhat.com> <4E3FEF94.8090506@codemonkey.ws> <4E3FF145.5000705@redhat.com> <4E3FF3A8.2040805@codemonkey.ws> In-Reply-To: <4E3FF3A8.2040805@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 05:33 PM, Anthony Liguori wrote: >> If we have a shared object helper, the thread should be maintained by >> qemu proper, not the plugin. >> >> I wouldn't call it "migration transport", but instead a >> compression/decompression plugin. >> >> I don't think it merits a plugin at all though. There's limited scope >> for compression and it best sits in qemu proper. If anything, it needs >> to be more integrated (for example turning itself off if it doesn't >> match enough). > > > That adds a tremendous amount of complexity to QEMU. Tremendous? You exaggerate. It's a lot simpler than the block or char layers, for example. > If we're going to change our compression algorithm, we would need to > use a single algorithm that worked well for a wide variety of workloads. That algorithm will have to include XBZRLE as a subset, since it matches what workloads actually do (touch memory sparsely). > > We struggle enough with migration as it is, it only would get worse if > we have 10 different algorithms that we were dynamically > enabling/disabling. > > The other option is to allow 1-off compression algorithms in the form > of plugins. I think in this case, plugins are a pretty good > compromise in terms of isolating complexity while allowing something > that at least works very well for one particular type of workload. I think you underestimate the generality of XBZRLE (or maybe I'm overestimating it?). It's not reasonable to ask users to match a compression algorithm to their workload; most times they won't be interacting with the host at all. We need compression to be enabled at all time, turning itself off if it finds it isn't effective so it can consume less cpu. -- error compiling committee.c: too many arguments to function