From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NUfHm-0002Ip-US
	for qemu-devel@nongnu.org; Tue, 12 Jan 2010 06:51:46 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NUfHi-0002Hw-33
	for qemu-devel@nongnu.org; Tue, 12 Jan 2010 06:51:46 -0500
Received: from [199.232.76.173] (port=60865 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NUfHh-0002Hr-Qw
	for qemu-devel@nongnu.org; Tue, 12 Jan 2010 06:51:41 -0500
Received: from mx20.gnu.org ([199.232.41.8]:1739)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jan.kiszka@siemens.com>)
	id 1NUfHg-0001nG-VW
	for qemu-devel@nongnu.org; Tue, 12 Jan 2010 06:51:41 -0500
Received: from thoth.sbs.de ([192.35.17.2])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <jan.kiszka@siemens.com>) id 1NUfHa-0000Xb-1a
	for qemu-devel@nongnu.org; Tue, 12 Jan 2010 06:51:34 -0500
Message-ID: <4B4C622D.5040800@siemens.com>
Date: Tue, 12 Jan 2010 12:51:09 +0100
From: Jan Kiszka <jan.kiszka@siemens.com>
MIME-Version: 1.0
References: <1263284833297-git-send-email-lirans@il.ibm.com>	<12632848342235-git-send-email-lirans@il.ibm.com>	<12632848343008-git-send-email-lirans@il.ibm.com>	<12632848351489-git-send-email-lirans@il.ibm.com>
	<12632848353279-git-send-email-lirans@il.ibm.com>
In-Reply-To: <12632848353279-git-send-email-lirans@il.ibm.com>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH 4/4] Try not to exceed max downtime on
	stage3
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Liran Schour <lirans@il.ibm.com>
Cc: qemu-devel@nongnu.org

Liran Schour wrote:
> Move to stage3 only when remaining work can be done below max downtime.
> To make sure the process will converge we will try only MAX_DIRTY_ITERATIONS.

OK, that explains now patch 2. But do we have such barrier for memory
migration as well? I don't thinks so, and I don't think this hard-coded
limit is the right approach. Such thing should be derived from the
bandwidth the user can control during runtime.

> 
> Signed-off-by: Liran Schour <lirans@il.ibm.com>
> ---
>  block-migration.c |   67 +++++++++++++++++++++++++++++++++++-----------------
>  1 files changed, 45 insertions(+), 22 deletions(-)
> 
> diff --git a/block-migration.c b/block-migration.c
> index 90c84b1..9ae04c4 100644
> --- a/block-migration.c
> +++ b/block-migration.c
> @@ -17,6 +17,7 @@
>  #include "qemu-queue.h"
>  #include "monitor.h"
>  #include "block-migration.h"
> +#include "migration.h"
>  #include <assert.h>
>  
>  #define BLOCK_SIZE (BDRV_SECTORS_PER_DIRTY_CHUNK << BDRV_SECTOR_BITS)
> @@ -30,6 +31,7 @@
>  #define BLOCKS_READ_CHANGE 100
>  #define INITIAL_BLOCKS_READ 100
>  #define MAX_DIRTY_ITERATIONS 100
> +#define DISK_RATE (30 << 20) //30 MB/sec

IMHO a bad idea (e.g. mine was 6 MB/s last time I tried). Measure it
during runtime just like the mem-migration does.

<skipping the rest of the patch>

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux