From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45199) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VT7Fr-00006Z-14 for qemu-devel@nongnu.org; Mon, 07 Oct 2013 05:37:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VT7Fm-0002Rl-9W for qemu-devel@nongnu.org; Mon, 07 Oct 2013 05:37:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45429) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VT7Fm-0002Rg-0Y for qemu-devel@nongnu.org; Mon, 07 Oct 2013 05:37:26 -0400 Message-ID: <525280C7.2050402@redhat.com> Date: Mon, 07 Oct 2013 11:37:11 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <20130117163740.7157.55600.malonedeb@gac.canonical.com> <20130926203354.30826.10562.malone@soybean.canonical.com> <52516C4A.6080508@gmail.com> <525256FC.6060608@dlhnet.de> In-Reply-To: <525256FC.6060608@dlhnet.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Bug 1100843] Re: Live Migration Causes Performance Issues List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: kvm@vger.kernel.org, gleb@redhat.com, quintela@redhat.com, mtosatti@redhat.com, qemu-devel , Zhang Haoyu , xiaoguangrong@linux.vnet.ibm.com, Bug 1100843 <1100843@bugs.launchpad.net>, mst@redhat.com, afaerber@suse.de Il 07/10/2013 08:38, Peter Lieven ha scritto: > On 06.10.2013 15:57, Zhang Haoyu wrote: >>> >From my testing this has been fixed in the saucy version (1.5.0) of >> qemu. It is fixed by this patch: >>> f1c72795af573b24a7da5eb52375c9aba8a37972 >>> >>> However later in the history this commit was reverted, and again broke >> this. The other commit that fixes this is: >>> 211ea74022f51164a7729030b28eec90b6c99a08 >>> >> See below post,please. >> https://lists.gnu.org/archive/html/qemu-devel/2013-08/msg05062.html > > I would still like to fix qemu to not load roms etc. if we set up a > migration target. In this case > we could drop the madvise, skip the checking for zero pages and also > could avoid sending > zero pages at all. It would be the cleanest solution. It's in general not easy to do this if you take non-x86 targets into account. Paolo