From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MeW9Q-0005o4-4a for qemu-devel@nongnu.org; Fri, 21 Aug 2009 11:35:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MeW9L-0005jd-2Y for qemu-devel@nongnu.org; Fri, 21 Aug 2009 11:35:35 -0400 Received: from [199.232.76.173] (port=50543 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MeW9K-0005jG-Mm for qemu-devel@nongnu.org; Fri, 21 Aug 2009 11:35:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:28775) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MeW9K-0002nl-6X for qemu-devel@nongnu.org; Fri, 21 Aug 2009 11:35:30 -0400 Message-ID: <4A8EBED6.7060105@redhat.com> Date: Fri, 21 Aug 2009 18:35:50 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/2] raw-posix: add Linux native AIO support References: <20090820145803.GA23578@lst.de> <20090820145835.GB24183@lst.de> <4A8E6EAD.3030809@redhat.com> <20090821144852.GA22645@lst.de> In-Reply-To: <20090821144852.GA22645@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: qemu-devel@nongnu.org On 08/21/2009 05:48 PM, Christoph Hellwig wrote: > 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. > You're right, virtio and scsi already know their queue sizes, should be easy to pass it down the stack. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.