From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1M6TlS-0007zs-Nb
	for qemu-devel@nongnu.org; Tue, 19 May 2009 14:10:10 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1M6TlO-0007xd-5H
	for qemu-devel@nongnu.org; Tue, 19 May 2009 14:10:10 -0400
Received: from [199.232.76.173] (port=53661 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1M6TlN-0007xV-Vd
	for qemu-devel@nongnu.org; Tue, 19 May 2009 14:10:05 -0400
Received: from rv-out-0708.google.com ([209.85.198.240]:40761)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1M6TlN-0006OG-Hu
	for qemu-devel@nongnu.org; Tue, 19 May 2009 14:10:05 -0400
Received: by rv-out-0708.google.com with SMTP id c5so2342043rvf.22
	for <qemu-devel@nongnu.org>; Tue, 19 May 2009 11:10:02 -0700 (PDT)
Message-ID: <4A12F5F6.2010003@codemonkey.ws>
Date: Tue, 19 May 2009 13:09:58 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] ram_save_live: add a no-progress convergence
	rule
References: <1242731347-1558-1-git-send-email-uril@redhat.com>
	<4A12AD80.701@codemonkey.ws>
	<20090519144101.GA16372@shell.devel.redhat.com>
In-Reply-To: <20090519144101.GA16372@shell.devel.redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Glauber Costa <glommer@redhat.com>
Cc: Uri Lublin <uril@redhat.com>, qemu-devel@nongnu.org

Glauber Costa wrote:
> Another possibility is for the management tool to increase the bandwidth for
> little periods if it perceives that no progress is being made.
>
> Anyhow, I completely agree that we should not introduce this in qemu.
>
> However, maybe we could augment our "info migrate" to provide more info about
> the internal state of migration, so the mgmt tool can take a more informed
> decision?
>   
Yes, I've also suggested this before.  I'm willing to expose just about 
any metric that makes sense.  We need to be careful about not exposing 
implementation details, but things like iteration count, last working 
set size, average working set size, etc. should all be relatively stable 
metrics even if the implementation changes.

Regards,

Anthony Liguori