From: Jamie Lokier Subject: Re: [PATCH] add support for vectored and async I/O to all simple filesystems Date: Wed, 2 Nov 2005 23:36:59 +0000 Message-ID: <20051102233659.GB20756@mail.shareable.org> References: <20051101023656.GA23724@lst.de> <20051101192000.GB29542@mail.shareable.org> <20051101205745.GB27231@kvack.org> <20051102110630.GB30550@mail.shareable.org> <20051102162107.GA32755@kvack.org> <20051102162904.GK23749@parisc-linux.org> <20051102203105.GA20756@mail.shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Matthew Wilcox , Benjamin LaHaise , Christoph Hellwig , akpm@osdl.org, linux-fsdevel@vger.kernel.org Return-path: Received: from mail.shareable.org ([81.29.64.88]:23966 "EHLO mail.shareable.org") by vger.kernel.org with ESMTP id S1030205AbVKBXhL (ORCPT ); Wed, 2 Nov 2005 18:37:11 -0500 To: Anton Altaparmakov Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Anton Altaparmakov wrote: > Yes, of course aio can block and in fact will block arbitrarily for > arbitrary lengths of time. At least at present the implementations of > ->aio_read and ->aio_write in the file systems will block left right and > center. > > [examples...] That's a shame. I was hoping it would offer similar properties to non-blocking I/O on sockets: something which can indicate that the resource is unavailable, but allows the application to continue with other things without needing parallel threads for that. > The only way you can _really_ have guaranteed async io is to queue the io > to a kernel thread work queue and return immediately to the caller. The > only thing you will then block on potentially is allocating memory for the > "queue entry item" and on waiting for the lock to the "queue" so it is > safe to write to it. Since threads with well-defined blocking points can be mechanically transformed to state machines, it is possible to guarantee async I/O without needing extra threads. I had wondered if the Linux AIO implementation did something like that. However, it is too complex to convert all filesystem code from blocking to state machines (by hand), and unnecessary. I've thought about possible AIO implementations many times, and always return to the idea of having AIOs be state machines which are handled synchronously and by interrupts, up until a point where a complex blocking point is reached in a filesystem (which shouldn't happen for the common read/write cases, but may happen for the uncommon ones), and then the AIOs convert to work handled by a worker thread spawned from a pool on demand. In other words, there are plenty of ways to guarantee properly async I/O. I'm surprised Linux AIO isn't - that seems to defeat the whole point of AIO. -- Jamie