From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IzZJC-00048P-7U for qemu-devel@nongnu.org; Tue, 04 Dec 2007 10:03:38 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IzZJA-00044k-8u for qemu-devel@nongnu.org; Tue, 04 Dec 2007 10:03:37 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IzZJA-00044a-5a for qemu-devel@nongnu.org; Tue, 04 Dec 2007 10:03:36 -0500 Received: from wa-out-1112.google.com ([209.85.146.176]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IzZJ9-0002dv-LM for qemu-devel@nongnu.org; Tue, 04 Dec 2007 10:03:35 -0500 Received: by wa-out-1112.google.com with SMTP id k22so6787030waf for ; Tue, 04 Dec 2007 07:03:34 -0800 (PST) Message-ID: <47556C2F.1010304@codemonkey.ws> Date: Tue, 04 Dec 2007 09:03:11 -0600 From: Anthony Liguori 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> <4755545E.6090609@redhat.com> In-Reply-To: <4755545E.6090609@redhat.com> Content-Type: text/plain; charset=UTF-8; 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 Gerd Hoffmann wrote: > 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. > I really want to use readv/writev though. With virtio, we get a scatter/gather list for each IO request. Once I post the virtio-blk driver, I'll follow up a little later with some refactoring of the block device layers. I think it can be made much simpler while still remaining asynchronous. > 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. > That's part of my plan. Regards, Anthony Liguori > cheers, > Gerd > > > >