From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:57189)
	by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <pl@kamp.de>)
	id 1VUBRS-0001bH-FG
	for qemu-devel@nongnu.org; Thu, 10 Oct 2013 04:18:02 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pl@kamp.de>) id 1VUBRK-0004E0-2o
	for qemu-devel@nongnu.org; Thu, 10 Oct 2013 04:17:54 -0400
Received: from mx.ipv6.kamp.de ([2a02:248:0:51::16]:34521 helo=mx01.kamp.de)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <pl@kamp.de>)
	id 1VUBRJ-0004Dg-Ni
	for qemu-devel@nongnu.org; Thu, 10 Oct 2013 04:17:46 -0400
Message-ID: <5256629F.10702@kamp.de>
Date: Thu, 10 Oct 2013 10:17:35 +0200
From: Peter Lieven <pl@kamp.de>
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> <525283A6.1070605@dlhnet.de>
	<52528508.4030204@redhat.com>
In-Reply-To: <52528508.4030204@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: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, gleb@redhat.com, quintela@redhat.com, mtosatti@redhat.com, qemu-devel <qemu-devel@nongnu.org>, Zhang Haoyu <ahzhanghaoyu@gmail.com>, xiaoguangrong@linux.vnet.ibm.com, Bug 1100843 <1100843@bugs.launchpad.net>, mst@redhat.com, afaerber@suse.de

On 07.10.2013 11:55, Paolo Bonzini wrote:
> Il 07/10/2013 11:49, Peter Lieven ha scritto:
>>> 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?
> I'm not sure I follow?
sth like this for each ram block at the beginning of ram_load.

  
+                    base = memory_region_get_ram_ptr(block->mr);
+                    for (offset = 0; offset < block->length;
+                         offset += TARGET_PAGE_SIZE) {
+                        if (!is_zero_page(base + offset)) {
+                            memset(base + offset, 0x00, TARGET_PAGE_SIZE);
+                        }
+                    }
+

Then add a capability "skip_zero_pages" which does not sent them on the source
and enables this zeroing. it would also be possible to skip the zero check
for each incoming compressed pages.

Peter