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

[Anthony Liguori <anthony@codemonkey.ws>]

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