From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:32924) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqRKN-0003o2-Gq for qemu-devel@nongnu.org; Mon, 08 Aug 2011 11:01:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QqRKM-00077Q-GH for qemu-devel@nongnu.org; Mon, 08 Aug 2011 11:01:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62532) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QqRKM-00077M-2S for qemu-devel@nongnu.org; Mon, 08 Aug 2011 11:01:14 -0400 Message-ID: <4E3FFA34.5010400@redhat.com> Date: Mon, 08 Aug 2011 18:01:08 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E3FF6AE.8030004@redhat.com> <4E3FF705.9080009@redhat.com> In-Reply-To: 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: Stefan Hajnoczi Cc: Blue Swirl , "Shribman, Aidan" , qemu-devel Developers 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