Re: [libvirt] [Qemu-devel] [PATCH v4] XBZRLE delta for live migration of large memory apps
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