From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MeVQK-0001nc-Ov
	for qemu-devel@nongnu.org; Fri, 21 Aug 2009 10:49:00 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MeVQG-0001c4-9i
	for qemu-devel@nongnu.org; Fri, 21 Aug 2009 10:49:00 -0400
Received: from [199.232.76.173] (port=45753 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MeVQG-0001bn-6w
	for qemu-devel@nongnu.org; Fri, 21 Aug 2009 10:48:56 -0400
Received: from verein.lst.de ([213.95.11.210]:58224)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60)
	(envelope-from <hch@lst.de>) id 1MeVQF-0003HF-IA
	for qemu-devel@nongnu.org; Fri, 21 Aug 2009 10:48:55 -0400
Date: Fri, 21 Aug 2009 16:48:52 +0200
From: Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] [PATCH 2/2] raw-posix: add Linux native AIO support
Message-ID: <20090821144852.GA22645@lst.de>
References: <20090820145803.GA23578@lst.de> <20090820145835.GB24183@lst.de>
	<4A8E6EAD.3030809@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A8E6EAD.3030809@redhat.com>
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: Avi Kivity <avi@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>, qemu-devel@nongnu.org

On Fri, Aug 21, 2009 at 12:53:49PM +0300, Avi Kivity wrote:
> >+ * Queue size (per-device).
> >+ *
> >+ * XXX: eventually we need to communicate this to the guest and/or make it
> >+ *      tunable by the guest.  If we get more outstanding requests at a 
> >time
> >+ *      than this we will get EAGAIN from io_submit which is communicated 
> >to
> >+ *      the guest as an I/O error.
> >+ */
> >+#define MAX_EVENTS 128
> >   
> 
> Or, we could queue any extra requests.

That doesn't make much sense.    We'd just do an additional level of
queueing in addition to those already optimized implementation in the
guest and host kernels.  This is really just an issue of communicating
the limits we have and deal with it efficiently.  It should be a
relatively small add-on patch.

> >+    if (io_setup(MAX_EVENTS,&s->ctx) != 0)
> >+        goto out_close_efd;
> >+
> >   
> 
> One day we may want a global io context so we can dequeue many events 
> with one syscall.  Or we may not, if we thread these things.

Wecould do this easily, in fact that's what I did before I run into
issues with the completion queue size when using multiple devices.

Syscall overhead in Linux is small enough that I would not bother until
it actually shows up as a problem.  That beeing said threading the block
layer would probably be a benefit for large setups for various reasons.