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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/08/2011 08:51 AM, Avi Kivity wrote:
On 08/08/2011 04:29 PM, Anthony Liguori wrote:

One thing that strikes me about this algorithm is that it's very good
for a particular type of workload--shockingly good really.

Poking bytes at random places in memory is fairly generic. If you have a
lot of small objects, and modify a subset of them, this is the pattern
you get.


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).

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).

Regards,

Anthony Liguori



--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]