From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LaFAw-00083X-VS
	for qemu-devel@nongnu.org; Thu, 19 Feb 2009 15:07:15 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LaFAv-00080J-2y
	for qemu-devel@nongnu.org; Thu, 19 Feb 2009 15:07:14 -0500
Received: from [199.232.76.173] (port=40989 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LaFAu-000808-VI
	for qemu-devel@nongnu.org; Thu, 19 Feb 2009 15:07:12 -0500
Received: from qw-out-1920.google.com ([74.125.92.148]:58336)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1LaFAu-0002do-Iy
	for qemu-devel@nongnu.org; Thu, 19 Feb 2009 15:07:12 -0500
Received: by qw-out-1920.google.com with SMTP id 4so176789qwk.4
	for <qemu-devel@nongnu.org>; Thu, 19 Feb 2009 12:07:12 -0800 (PST)
Message-ID: <499DBBD1.1020602@codemonkey.ws>
Date: Thu, 19 Feb 2009 14:06:41 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] migration: adding migration to/from a file (v2)
References: <499D4654.9000305@redhat.com>
	<499D652D.60803@codemonkey.ws>	<499D8564.1070007@redhat.com>
	<499D8E05.2060207@codemonkey.ws>
	<20090219193733.GB22319@shareable.org>
In-Reply-To: <20090219193733.GB22319@shareable.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
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: qemu-devel@nongnu.org
Cc: Uri Lublin <uril@redhat.com>

Jamie Lokier wrote:
>
>> Remember, migration is a streaming 
>> protocol, not a random access, so it only makes sense to have one 
>> outstanding request at a time.
>>     
>
> Fwow, often with streaming (in general) the highest performance comes
> from having two or more outstanding requests at a time, so there are
> no gaps between requests being processed at the OS and device level.
>
> However, unless migrate-to-file uses O_DIRECT that will be hidden by
> the OS's buffering.
>   

It's already buffered FWIW by the savevm infrastructure.  You'll won't 
usually see small operations.

Regards,

Anthony Liguori

> Then the remaining overhead from AIOs (or fake AIOs using threads) is
> lots context switching, one per write completed.
>
> -- Jamie
>
>
>