On 08/08/2011 05:56 PM, Stefan Hajnoczi wrote:
> IOW, this should be part of the standard migration protocol, not some side
> option that is enabled if the user remembers. It should not be mutually
> exclusive with future migration extensions, including compression.
This is an attractive option. With some polish maybe XBZRLE could be
integrated as a default option that does not degrade performance.
Adding features that require user configuration isn't worthwhile
because they won't be used or they'll be misused - let's not make QEMU
more complicated if it can be avoided.
If there is no way to make XBZRLE automatic then I think it should
live outside QEMU because it will be a niche feature that relatively
few will use but adds complexity to migration.
Agree. Aidan, can you provide impact numbers on non-XBZRLE favourable
workloads (both throughput and cpu usage)? What about turning itself
off automatically if the hit rate is too low?
--
error compiling committee.c: too many arguments to function