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