From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:42788)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <s.priebe@profihost.ag>) id 1TRUJF-0004Xn-Gp
	for qemu-devel@nongnu.org; Thu, 25 Oct 2012 16:45:46 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <s.priebe@profihost.ag>) id 1TRUJD-0005Ru-8n
	for qemu-devel@nongnu.org; Thu, 25 Oct 2012 16:45:45 -0400
Received: from mail.profihost.ag ([85.158.179.208]:49362)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <s.priebe@profihost.ag>) id 1TRUJC-0005Ro-VX
	for qemu-devel@nongnu.org; Thu, 25 Oct 2012 16:45:43 -0400
Message-ID: <5089A4F5.6020306@profihost.ag>
Date: Thu, 25 Oct 2012 22:45:41 +0200
From: Stefan Priebe <s.priebe@profihost.ag>
MIME-Version: 1.0
References: <5088F46D.6080605@profihost.ag> <508909F4.8020100@redhat.com>
	<508915DE.5080509@profihost.ag> <508924E1.3@redhat.com>
	<50892E08.5090404@profihost.ag> <50893B7A.2010800@redhat.com>
In-Reply-To: <50893B7A.2010800@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] slow xbzrle
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: Orit Wasserman <owasserm@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>

Am 25.10.2012 15:15, schrieb Orit Wasserman:
>>> Looks like a lot of cache miss, you can try increasing the cache size (migrate_set_cache_size).
>>> But you should remember that for an idle guest XBZRLE is wasteful,
>>> it is useful for workload that changes the same memory pages frequently.
>>
>> sure here are some values from a loaded VM (20% cpu load with MySQL) - with an increased cache size does not look much better:
>>
>> Oct 25 14:16:39 migration xbzrle cachesize: 536870912 transferred 0 pages 0 cachemiss 159634 overflow 0
>> Oct 25 14:16:41 migration xbzrle cachesize: 536870912 transferred 0 pages 0 cachemiss 173631 overflow 0
>> Oct 25 14:16:43 migration xbzrle cachesize: 536870912 transferred 0 pages 0 cachemiss 187627 overflow 0
>> Oct 25 14:16:45 migration xbzrle cachesize: 536870912 transferred 0 pages 0 cachemiss 201624 overflow 0
> It looks like the cache got smaller 1073741824 > 536870912 ...
> try 2G cache size
> Orit

Here from another VM running into overflow setting cache size to 50% of mem:
Oct 25 22:43:57 migration xbzrle cachesize: 2147483648 transferred 
36294204 pages 520357 cachemiss 392074 overflow 947

Oct 25 22:44:31 migration xbzrle cachesize: 2147483648 transferred 
45438419 pages 653350 cachemiss 392091 overflow 1024

Oct 25 22:44:55 migration xbzrle cachesize: 2147483648 transferred 
51310028 pages 742877 cachemiss 392096 overflow 1054

Greets,
Stefan