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

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

On 08/08/2011 09:39 AM, Avi Kivity wrote:
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.

I think you underestimate the generality of XBZRLE (or maybe I'm
overestimating it?).

This is really my fundamental concern. When it comes to something that we have to support for a very long time, no one should be estimating anything. We should make these decisions based on an awful lot of analysis on a wide variety of workloads.

It's hard to do this in QEMU today because we don't have a module mechanism to make it easy for users to try out new things without fully committing to including something in the tree.

But I don't think that's the root of the problem I have. I really am just extremely reluctant to commit to something that we have to support forever.

Thinking more about it though, I think there can be another solution--feature negotiation.

I view adding feature negotiation as a pre-requisite to adding any type of transport compression such as XBZRLE. That will let us support migration to older QEMUs and also to eventually remove XBZRLE if we decide it doesn't make sense anymore.


Anthony Liguori

It's not reasonable to ask users to match a
compression algorithm to their workload; most times they won't be
interacting with the host at all. We need compression to be enabled at
all time, turning itself off if it finds it isn't effective so it can
consume less cpu.

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