LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Nate Diller" <email@example.com>
To: "David Brownell" <firstname.lastname@example.org>
Cc: "Nate Diller" <email@example.com>, "Andrew Morton" <firstname.lastname@example.org>,
"Alan Cox" <email@example.com>,
"Trond Myklebust" <firstname.lastname@example.org>,
"Benjamin LaHaise" <email@example.com>,
"Alexander Viro" <firstname.lastname@example.org>,
"Suparna Bhattacharya" <email@example.com>,
"Kenneth W Chen" <firstname.lastname@example.org>,
"David Brownell" <email@example.com>,
"Christoph Hellwig" <firstname.lastname@example.org>,
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: <email@example.com> (raw)
On 1/15/07, David Brownell <firstname.lastname@example.org> 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.
next prev parent 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
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).