From mboxrd@z Thu Jan  1 00:00:00 1970
From: Peter Lieven <lieven-lists@dlhnet.de>
Subject: Re: [Qemu-devel] [Bug 1100843] Re: Live Migration Causes Performance
 Issues
Date: Mon, 07 Oct 2013 11:49:26 +0200
Message-ID: <525283A6.1070605@dlhnet.de>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Zhang Haoyu <ahzhanghaoyu@gmail.com>,
	Bug 1100843 <1100843@bugs.launchpad.net>, gleb@redhat.com,
	eblake@redhat.com, quintela@redhat.com, afaerber@suse.de,
	xiaoguangrong@linux.vnet.ibm.com, mtosatti@redhat.com,
	kvm@vger.kernel.org, mst@redhat.com,
	qemu-devel <qemu-devel@nongnu.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from ssl.dlhnet.de ([91.198.192.8]:57727 "EHLO ssl.dlh.net"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1754969Ab3JGJt3 (ORCPT <rfc822;kvm@vger.kernel.org>);
	Mon, 7 Oct 2013 05:49:29 -0400
In-Reply-To: <525280C7.2050402@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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