From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47184) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqRRP-0005Ct-Si for qemu-devel@nongnu.org; Mon, 08 Aug 2011 11:08:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QqRRJ-00089N-C0 for qemu-devel@nongnu.org; Mon, 08 Aug 2011 11:08:26 -0400 Received: from mail-pz0-f42.google.com ([209.85.210.42]:54955) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqRRJ-00089F-44 for qemu-devel@nongnu.org; Mon, 08 Aug 2011 11:08:25 -0400 Received: by pzk37 with SMTP id 37so3145015pzk.29 for ; Mon, 08 Aug 2011 08:08:24 -0700 (PDT) Message-ID: <4E3FFBE4.9060206@codemonkey.ws> Date: Mon, 08 Aug 2011 10:08:20 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4E3FE4CF.4060108@codemonkey.ws> <4E3FE9F0.9070702@redhat.com> <4E3FEF94.8090506@codemonkey.ws> <4E3FF145.5000705@redhat.com> <4E3FF3A8.2040805@codemonkey.ws> <4E3FF524.7070509@redhat.com> In-Reply-To: <4E3FF524.7070509@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4] XBZRLE delta for live migration of large memory apps List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Stefan Hajnoczi , Dor Laor , qemu-devel Developers , libvirt-list@redhat.com, Blue Swirl , "Shribman, Aidan" 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. >