LKML Archive on
help / color / mirror / Atom feed
From: Alan Stern <>
To: Kernel development list <>
Cc: Sarah Bailey <>,
	USB development list <>
Subject: [linux-usb-devel] usbfs2: Why asynchronous I/O?
Date: Sun, 25 Feb 2007 11:51:46 -0500 (EST)	[thread overview]
Message-ID: <> (raw)

This deserves to be discussed on LKML.

Alan Stern

---------- Forwarded message ----------
Date: Sun, 25 Feb 2007 00:57:55 -0800
From: Sarah Bailey <>
To: David Brownell <>,
Subject: [linux-usb-devel] usbfs2: Why asynchronous I/O?

I've been doing some research into how asynchronous I/O is implemented,
and I'm beginning to doubt the usefulness of implementing aio_read
and aio_write in usbfs2.  More detail on what I've learned can be found

It was a surprise to me that aio_read(3) and aio_write(3) don't actually
end up calling aio_read and aio_write file operations.  Instead, GNU
libc spawns threads that call the blocking read and write file

I haven't seen any evidence that the kernel-side aio is substantially
more efficient than the GNU libc implementation, so it seems like it
would be better to leave the complexity in userspace.  I also doubt that
most userspace application writers know they aren't getting kernel-side
aio when they use aio_read(3) and aio_write(3).  Why implement something
that isn't going to be used?

There are few examples in the kernel where the aio API is implemented in
a truly asynchronous manner, and that leads me to wonder if the aio
system has been thoroughly tested.  The majority of aio_read and
aio_write file operations simply block and wait for their transactions
to complete.

The only "proper" async examples I could find were gadgetfs, NFS, and
block devices.  NFS and block devices only use aio when the O_DIRECT
flag is set, so that code may not be well tested.  I just found a bug in
gadgetfs that has been there for six months that means the code wasn't
tested for when io_submit is called in readv mode.

So, why do I want a non-blocking aio_read and aio_write file operation?
It's useful to have read and readv implemented automatically from
aio_read, but I see no substantial benefit to implementing aio_read in a
non-blocking way.

Sarah Bailey

             reply	other threads:[~2007-02-25 16:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20070225085755.GA4886@localdomain>
     [not found] ` <>
     [not found]   ` <>
2007-02-25 16:51     ` Alan Stern [this message]
2007-02-25 23:55       ` Greg KH
2007-02-26  2:22         ` Alan Stern
2007-02-26  8:54       ` Sarah Bailey
2007-02-27  0:20         ` Greg KH
2007-02-28 20:03         ` David Brownell
2007-02-25 17:42 David Brownell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: [linux-usb-devel] usbfs2: Why asynchronous I/O?' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).