From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49133) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VT7RW-0007Pr-J3 for qemu-devel@nongnu.org; Mon, 07 Oct 2013 05:49:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VT7RQ-0006Oq-ND for qemu-devel@nongnu.org; Mon, 07 Oct 2013 05:49:34 -0400 Received: from ssl.dlhnet.de ([91.198.192.8]:57325 helo=ssl.dlh.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VT7RQ-0006Oj-HV for qemu-devel@nongnu.org; Mon, 07 Oct 2013 05:49:28 -0400 Message-ID: <525283A6.1070605@dlhnet.de> Date: Mon, 07 Oct 2013 11:49:26 +0200 From: Peter Lieven 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> <525280C7.2050402@redhat.com> In-Reply-To: <525280C7.2050402@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Paolo Bonzini 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 On 07.10.2013 11:37, Paolo Bonzini wrote: > 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. What about the dirty way to zero out all non zero pages at the beginning of ram_load? Peter