LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Kernel development list <linux-kernel@vger.kernel.org>
Cc: Sarah Bailey <saharabeara@gmail.com>,
	<usb-hacking@svcs.cs.pdx.edu>,
	USB development list <linux-usb-devel@lists.sourceforge.net>
Subject: [linux-usb-devel] usbfs2: Why asynchronous I/O?
Date: Sun, 25 Feb 2007 11:51:46 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.0702251147500.25265-100000@netrider.rowland.org> (raw)

This deserves to be discussed on LKML.

Alan Stern

---------- Forwarded message ----------
Date: Sun, 25 Feb 2007 00:57:55 -0800
From: Sarah Bailey <saharabeara@gmail.com>
To: David Brownell <david-b@pacbell.net>, greg@kroah.com
Cc: usb-hacking@svcs.cs.pdx.edu, linux-usb-devel@lists.sourceforge.net
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
at http://wiki.cs.pdx.edu/usb/asyncdebate.html

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
operations.

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] ` <200702250853.03851.david-b@pacbell.net>
     [not found]   ` <20070225173302.GA12190@comsec.com>
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=Pine.LNX.4.44L0.0702251147500.25265-100000@netrider.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=saharabeara@gmail.com \
    --cc=usb-hacking@svcs.cs.pdx.edu \
    --subject='Re: [linux-usb-devel] usbfs2: Why asynchronous I/O?' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).