Re: [Qemu-devel] [PATCH v4] XBZRLE delta for live migration of large memory apps

[Anthony Liguori]

On 08/08/2011 09:23 AM, Avi Kivity wrote:
> On 08/08/2011 05:15 PM, Anthony Liguori wrote:
> > 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).

That adds a tremendous amount of complexity to QEMU.  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.

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.

Regards,

Anthony Liguori