From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IzXiU-00028I-LV for qemu-devel@nongnu.org; Tue, 04 Dec 2007 08:21:38 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IzXiT-00027y-Ax for qemu-devel@nongnu.org; Tue, 04 Dec 2007 08:21:38 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IzXiT-00027v-78 for qemu-devel@nongnu.org; Tue, 04 Dec 2007 08:21:37 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IzXiS-0007IG-Vm for qemu-devel@nongnu.org; Tue, 04 Dec 2007 08:21:37 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.1) with ESMTP id lB4DLa8h007775 for ; Tue, 4 Dec 2007 08:21:36 -0500 Received: from pobox.stuttgart.redhat.com (pobox.stuttgart.redhat.com [172.16.2.10]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lB4DLZ2b003889 for ; Tue, 4 Dec 2007 08:21:35 -0500 Received: from zweiblum.travel.kraxel.org (vpn-4-1.str.redhat.com [10.32.4.1]) by pobox.stuttgart.redhat.com (8.13.1/8.13.1) with ESMTP id lB4DLYkx029592 for ; Tue, 4 Dec 2007 08:21:34 -0500 Message-ID: <4755545E.6090609@redhat.com> Date: Tue, 04 Dec 2007 14:21:34 +0100 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/2 v2] Direct IDE I/O References: <11966765602186@bull.net> <4753D920.4060500@bellard.org> <1196677804.5275.5.camel@frecb07144> <475426C7.20503@codemonkey.ws> <20071203170800.GC3797@implementation> <47544588.10700@codemonkey.ws> <1196709044.5587.20.camel@frecb07144> <47547163.1020604@redhat.com> <47547753.2050101@codemonkey.ws> In-Reply-To: <47547753.2050101@codemonkey.ws> Content-Type: text/plain; charset=UTF-8 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 Anthony Liguori wrote: >> IMHO it would be a much better idea to kill the aio interface altogether >> and instead make the block drivers reentrant. Then you can use >> (multiple) posix threads to run the I/O async if you want. > > Threads are a poor substitute for a proper AIO interface. linux-aio > gives you everything you could possibly want in an interface since it > allows you to submit multiple vectored operations in a single syscall, > use an fd to signal request completion, complete multiple requests in a > single syscall, and inject barriers via fdsync. I still think implementing async i/o at block driver level is the wrong thing to do. You'll end up reinventing the wheel over and over again and add complexity to the block drivers which simply doesn't belong there (or not supporting async I/O for most file formats). Just look at the insane file size of the block driver for the simplest possible disk format: block-raw.c. It will become even worse when adding a linux-specific aio variant. In contrast: Making the disk drivers reentrant should be easy for most of them. For the raw driver it should be just using pread/pwrite syscalls instead of lseek + read/write (also saves a syscall along the way, yea!). Others probably need an additional lock for metadata updates. With that in place you can easily implement async I/O via threads one layer above, and only once, in block.c. IMHO the only alternative to that scheme would be to turn the block drivers in some kind of remapping drivers for the various file formats which don't actually perform the I/O. Then you can handle the actual I/O in a generic way using whatever API is available, be it posix-aio, linux-aio or slow-sync-io. cheers, Gerd