|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [PATCH v4] XBZRLE delta for live migration of large memory apps |
Date: | Mon, 08 Aug 2011 10:08:20 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 |
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.
Regards, 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.
[Prev in Thread] | Current Thread | [Next in Thread] |