From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L6uvq-00020D-Ea for qemu-devel@nongnu.org; Sun, 30 Nov 2008 17:38:26 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L6uvo-0001z5-K0 for qemu-devel@nongnu.org; Sun, 30 Nov 2008 17:38:25 -0500 Received: from [199.232.76.173] (port=56597 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L6uvo-0001yx-BQ for qemu-devel@nongnu.org; Sun, 30 Nov 2008 17:38:24 -0500 Received: from an-out-0708.google.com ([209.85.132.246]:6161) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L6uvo-0004KG-1X for qemu-devel@nongnu.org; Sun, 30 Nov 2008 17:38:24 -0500 Received: by an-out-0708.google.com with SMTP id c38so735519ana.37 for ; Sun, 30 Nov 2008 14:38:23 -0800 (PST) Message-ID: <493315DB.5060102@codemonkey.ws> Date: Sun, 30 Nov 2008 16:38:19 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC 1/2] pci-dma-api-v1 References: <20081127123538.GC10348@random.random> <20081128015602.GA31011@random.random> <20081128185001.GD31011@random.random> In-Reply-To: <20081128185001.GD31011@random.random> 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: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Blue Swirl Andrea Arcangeli wrote: > On Fri, Nov 28, 2008 at 07:59:13PM +0200, Blue Swirl wrote: > >> I don't know, here's a pointer: >> http://lists.gnu.org/archive/html/qemu-devel/2008-08/msg00092.html >> > > I'm in total agreement with it. The missing "proper vectored AIO > operations" are bdrv_aio_readv/writev ;). > > I wonder how can possibly aio_readv/writev be missing in posix aio? > Because it sucks. > Unbelievable. It'd be totally trivial to add those to glibc, much > easier infact than to pthread_create by hand, but how can we add a > dependency on a certain glibc version? I've already asked, Ulrich will not likely add this unless it first goes into the Posix standard. It won't go into the Posix standard without an existing implementation. Either way, we're talking about a multi-year process. We need our own thread-pool based AIO implementation. > Ironically it'll be more > user-friendly to add dependency on linux kernel-aio implementation > that is already available for ages and it's guaranteed to run faster > (or at least not slower). > No, kernel-aio is more brain dead. io_submit may block if the underlying file descriptor does not support asynchronous IO. There is no way to detect this. This means the only safe way to use io_submit is to call it from a thread, and to have a thread pool that can do multiple io_submits in parallel. Yes, that's ridiculous. There's a thread right now on linux-aio@vger.kernel.org discussing the future of linux-aio. The prevailing wisdom seems to be that linux-aio does not have a future. Regards, Anthony Liguori