LKML Archive on
help / color / mirror / Atom feed
From: "Nate Diller" <>
To: "David Brownell" <>
Cc: "Nate Diller" <>, "Andrew Morton" <>,
	"Alan Cox" <>,
	"Trond Myklebust" <>,
	"Benjamin LaHaise" <>,
	"Alexander Viro" <>,
	"Suparna Bhattacharya" <>,
	"Kenneth W Chen" <>,
	"David Brownell" <>,
	"Christoph Hellwig" <>,,,,,,
Subject: Re: [PATCH -mm 9/10][RFC] aio: usb gadget remove aio file ops
Date: Tue, 16 Jan 2007 01:13:45 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 1/15/07, David Brownell <> wrote:
> On Monday 15 January 2007 5:54 pm, Nate Diller wrote:
> > This removes the aio implementation from the usb gadget file system.
> NAK.  I see a deep mis-understanding here.
> > Aside
> > from making very creative (!) use of the aio retry path, it can't be of any
> > use performance-wise
> Other than the basic win of letting one userspace thread keep an I/O
> stream active while at the same time processing the data it reads or
> writes??  That's the "async" part of AIO.
> There's a not-so-little thing called "I/O overlap" ... which is the only
> way to prevent wasting bandwidth between (non-cacheable) I/O requests,
> and thus is the only way to let userspace code achieve anything close
> to the maximum I/O bandwidth the hardware can achieve.
> We want to see the host side "usbfs" evolve to support AIO like this
> too, for the same reasons.  (Currently it has fairly ugly AIO code
> that looks unlike any other AIO code in Linux.  Recent updates to
> support a file-per-endpoint device model are a necessary precursor
> to switching over to standard AIO syscalls.)
> > because it always kmalloc()s a bounce buffer for the
> > *whole* I/O size.
> By and large that's a negligible factor compared to being able to
> achieve I/O overlap.  ISTR the reason for not doing fancy DMA magic
> was that the cost of this style AIO was under 1 KByte object code
> on ARM, which was easy to justify ... while DMA magic to do that
> sort of stuff would be much fatter, as well as more error prone.
> (And that's why the "creative" use of the retry path.  As I've
> observed before, "retry" is a misnomer in the general sense of
> an async I/O framework.  It's more of a semi-completion callback;
> I/O can't in general be "retried" on error or fault, and even in
> the current usage it's not really a "retry".)
> Now that high speed peripheral hardware is becoming more common on
> embedded Linuxes -- TI has DaVinci, OMAP 2430, TUSB6010 (as found
> in the new Nokia 800 tablets); Atmel AVR32 AP7000; at least a couple
> parts that should be able to use the same musb_hdrc driver as those
> TI parts; and a few other chips I've heard of -- there may be some
> virtue in eliminating the memcpy, since those CPUs don't have many
> MIPS to waste.  (Iff the memcpy turns out to be a real issue...)
> > Perhaps the only reason to keep it around is the ability
> > to cancel I/O requests, which only applies when using the user space async
> > I/O interface.
> It's good to have almost the complete kernel API functionality
> exposed to userspace, and having I/O cancelation is an inevitable
> consequence of a complete AIO framework ... but that particular
> issue was not a driving concern.
> The reason for AIO is to have a *STANDARD* userspace interface
> for *ASYNC I/O* which otherwise can't exist.  You know, the kind
> of I/O interface that can't be implemented with read() and write()
> syscalls, which for non-buffered I/O necessarily preclude all I/O
> overlap.  AIO itself is a direct match to most I/O frameworks'
> primitives.  (AIOCB being directly analagous to peripheral side
> "struct usb_request" and host side "struct urb".)
> You know, I've always thought that one reason the AIO discussions
> seemed strange is that they weren't really focussed on I/O (the
> lowlevel after-the-caches stuff) so much as filesystems (several
> layers up in the stack, with intervening caching frameworks).
> The first several implementations of AIO that I saw were restricted
> to "real" I/O and not applicable to disk backed files.  So while I
> was glad the Linux approach didn't make that mistake, it's seemed
> that it might be wanting to make a converse mistake: neglecting I/O
> that isn't aimed at data stored on disks.
> > I highly doubt that is enough incentive to justify the extra
> > complexity here or in user-space, so I think it's a safe bet to remove this.
> > If that feature still desired, it would be possible to implement a sync
> > interface that does an interruptible sleep.
> What's needed is an async, non-sleeeping, interface ... with I/O
> overlap.  That's antithetical to using read()/write() calls, so
> your proposed approach couldn't possibly work.

haha, wow ok you convinced me :)

I got a bit impatient when I was working on this, it took some time
just to figure out the intention of the code, and I'm trying to hold
to a bit of a schedule here.  Without any clear (to me) reason, I
didn't want to spend a lot of effort fixing this up.

There's really no big difference between the usb drivers here and the
disk I/O scheduler queue, AFAICT, so it seems like the solution I want
is to do a kmap() on the user buffer and then do the I/O straight out
of that.  That will eliminate the need for the bounce buffer.  I'll
post a new version along with the iodesc changes later this week.


  reply	other threads:[~2007-01-16  9:13 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-16  1:54 [PATCH -mm 0/10][RFC] aio: make struct kiocb private Nate Diller
2007-01-16  1:54 ` [PATCH -mm 7/10][RFC] aio: make __blockdev_direct_IO use file_endio_t Nate Diller
2007-01-16  1:54 ` [PATCH -mm 4/10][RFC] aio: convert aio_complete to file_endio_t Nate Diller
2007-01-16  5:53   ` David Brownell
2007-01-16  9:21     ` Nate Diller
2007-01-16  1:54 ` [PATCH -mm 5/10][RFC] aio: make blk_directIO use file_endio_t Nate Diller
2007-01-16  1:54 ` [PATCH -mm 8/10][RFC] aio: make direct_IO aops " Nate Diller
2007-01-16  1:54 ` [PATCH -mm 1/10][RFC] aio: scm remove struct siocb Nate Diller
2007-01-16  1:54 ` [PATCH -mm 6/10][RFC] aio: make nfs_directIO use file_endio_t Nate Diller
2007-01-16  1:54 ` [PATCH -mm 10/10][RFC] aio: convert file aio to file_endio_t Nate Diller
2007-01-16  1:54 ` [PATCH -mm 2/10][RFC] aio: net use struct socket for io Nate Diller
2007-01-16  5:44   ` Stephen Hemminger
2007-01-16 10:24     ` Evgeniy Polyakov
2007-01-16  1:54 ` [PATCH -mm 9/10][RFC] aio: usb gadget remove aio file ops Nate Diller
2007-01-16  6:05   ` David Brownell
2007-01-16  9:13     ` Nate Diller [this message]
2007-01-16 18:36       ` David Brownell
2007-01-16  1:54 ` [PATCH -mm 3/10][RFC] aio: use iov_length instead of ki_left Nate Diller
2007-01-16  2:14   ` Christoph Hellwig
2007-01-16  5:37     ` Nate Diller
2007-01-16 23:36       ` Ingo Oeser
2007-01-18  4:27     ` Vectored AIO breakage for sockets and pipes ? Suparna Bhattacharya
2007-01-18 21:40       ` Zach Brown
2007-01-16  3:23 ` [PATCH -mm 0/10][RFC] aio: make struct kiocb private Christoph Hellwig
2007-01-16  4:25   ` Nate Diller
2007-01-16  8:22     ` David Brownell
2007-01-17 21:52     ` Benjamin LaHaise
2007-01-17 23:30       ` Nate Diller

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: [PATCH -mm 9/10][RFC] aio: usb gadget remove aio file ops' \

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