From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54843) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqQjc-0007L2-MN for qemu-devel@nongnu.org; Mon, 08 Aug 2011 10:23:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QqQjb-0007oU-DV for qemu-devel@nongnu.org; Mon, 08 Aug 2011 10:23:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37957) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqQjb-0007oM-36 for qemu-devel@nongnu.org; Mon, 08 Aug 2011 10:23:15 -0400 Message-ID: <4E3FF145.5000705@redhat.com> Date: Mon, 08 Aug 2011 17:23:01 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E3FE4CF.4060108@codemonkey.ws> <4E3FE9F0.9070702@redhat.com> <4E3FEF94.8090506@codemonkey.ws> In-Reply-To: <4E3FEF94.8090506@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:15 PM, Anthony Liguori wrote: >> >>> >>> 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. > > > exec helpers are plugins. They just live in a different address space > and a channel to exchange data (pipe). libvirt isn't an exec helper. > > If we did .so plugins, which I'm really not opposed to, I'd want the > interface to be something like: > > typedef struct MigrationTransportClass > { > ssize_t (*writev)(MigrationTransport *obj, > struct iovec *iov, > int iovcnt); > } MigrationTransportClass; > > I think it's useful to use an interface like this because it makes it > easy to put the transport in a dedicated thread that didn't hold > qemu_mutex (which is sort of equivalent to using a fork'd helper but > is zero-copy at the expense of less isolation). 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). -- error compiling committee.c: too many arguments to function