Re: [PATCH] add support for vectored and async I/O to all simple filesystems

[Jamie Lokier <jamie@shareable.org>]

Matthew Wilcox wrote:
> On Wed, Nov 02, 2005 at 11:21:07AM -0500, Benjamin LaHaise wrote:
> > On Wed, Nov 02, 2005 at 11:06:30AM +0000, Jamie Lokier wrote:
> > > So it means that any program that mustn't block, must now have a
> > > stupid kernel version check to make sure it avoids even trying aio
> > > system calls?  I was under the impression that the right thing to do
> > > so far was try them, and when EINVAL is returned, use threads instead.
> > 
> > Yes, that is correct.
> 
> To be fair, the aio system calls were never _guaranteed_ to not block,
> were they?  ISTR there were various corner cases that would still get
> your task  blocking while doing an aio submission.

Could we have some documentation of when those corner cases occur?

The main point of aio, as far as I'm aware, is to avoid the need for
threads (or reduce the number of threads) in programs using I/O that
shouldn't block, particularly when they are latency sensitive too.

If aio has a habit of blocking from time to time, then it may still be
useful, but it would be helpful to know that multiple threads are
still needed to ensure a program (e.g. such as a HTTP or SMB server)
can continue to make progress - and more helpful to know when.

One particular question is: can aio calls block for a long time due to
network delays (e.g. over NFS) and I/O delays (e.g. slow disk or CD),
or are the corner cases restricted to things like paging during memory
allocation, which is unavoidable one way or another anyway?

-- Jamie