From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MGUjk-0007jX-8V
	for qemu-devel@nongnu.org; Tue, 16 Jun 2009 05:13:48 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MGUjf-0007iG-JL
	for qemu-devel@nongnu.org; Tue, 16 Jun 2009 05:13:47 -0400
Received: from [199.232.76.173] (port=55797 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MGUjf-0007hz-BX
	for qemu-devel@nongnu.org; Tue, 16 Jun 2009 05:13:43 -0400
Received: from mx2.redhat.com ([66.187.237.31]:56029)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1MGUje-0005Ee-Ux
	for qemu-devel@nongnu.org; Tue, 16 Jun 2009 05:13:43 -0400
Message-ID: <4A37624E.4040503@redhat.com>
Date: Tue, 16 Jun 2009 12:13:50 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <4A36B025.2080602@us.ibm.com> <4A37618E.6040606@redhat.com>
In-Reply-To: <4A37618E.6040606@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: Live migration broken when under heavy IO
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: Anthony Liguori <aliguori@us.ibm.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, kvm-devel <kvm@vger.kernel.org>

On 06/16/2009 12:10 PM, Avi Kivity wrote:
>> Does anyone have a clever idea how to fix this without just waiting 
>> for all IO requests to complete?
>
> What's wrong with waiting for requests to complete?  It should take a 
> few tens of milliseconds.
>
> We could start throttling requests late in the live stage, but I don't 
> really see the point.

Well, we can introduce a new live stage, where we migrate RAM and 
complete block requests, but the vm is otherwise stopped.  This allows 
the flush to overlap with sending memory dirtied by the flush, reducing 
some downtime.  Since block requests can dirty large amounts of memory, 
this may be significant.

We can even keep the vcpu alive, only blocking new block requests, but 
that may cause dirty RAM divergence.

-- 
error compiling committee.c: too many arguments to function