[Top] [All Lists]

[xfs-masters] Re: [PATCH -mm 9/10][RFC] aio: usb gadget remove aio file

To: "Nate Diller" <nate.diller@xxxxxxxxx>
Subject: [xfs-masters] Re: [PATCH -mm 9/10][RFC] aio: usb gadget remove aio file ops
From: David Brownell <david-b@xxxxxxxxxxx>
Date: Tue, 16 Jan 2007 10:36:42 -0800
Cc: "Nate Diller" <nate@xxxxxxxxx>, "Andrew Morton" <akpm@xxxxxxxx>, "Alan Cox" <alan@xxxxxxxxxxxxxxxxxxx>, "Trond Myklebust" <trond.myklebust@xxxxxxxxxx>, "Benjamin LaHaise" <bcrl@xxxxxxxxx>, "Alexander Viro" <viro@xxxxxxxxxxxxxxxxxx>, "Suparna Bhattacharya" <suparna@xxxxxxxxxx>, "Kenneth W Chen" <kenneth.w.chen@xxxxxxxxx>, "David Brownell" <dbrownell@xxxxxxxxxxxxxxxxxxxxx>, "Christoph Hellwig" <hch@xxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxxxxxx, ocfs2-devel@xxxxxxxxxxxxxx, linux-aio@xxxxxxxxx, xfs-masters@xxxxxxxxxxx
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=Received:X-YMail-OSG:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=0m6IK3fXn5onpoEBekZqYcs7yHK/EeZ425uOXOHbHaO2ck3RrZfGmPNhKxlAYeWIhlcJO5Xo5pOut4cc/Xe2FBHbzjyMUiWf/wYfQ5zitvhNNiYZXj3vZXWrVr5ZBXPEpx/TPAq3RT5vPeiS1MZFXYRoF5SZ7BsoDDFhKweNMGQ= ;
In-reply-to: <5c49b0ed0701160113i8866879y3a134461c4ae7974@xxxxxxxxxxxxxx>
References: <20070116015450.9764.62432.patchbomb.py@xxxxxxxxxxxxxxxxx> <200701152205.46089.david-b@xxxxxxxxxxx> <5c49b0ed0701160113i8866879y3a134461c4ae7974@xxxxxxxxxxxxxx>
Reply-to: xfs-masters@xxxxxxxxxxx
Sender: xfs-masters-bounce@xxxxxxxxxxx
User-agent: KMail/1.7.1
On Tuesday 16 January 2007 1:13 am, Nate Diller wrote:
> On 1/15/07, David Brownell <david-b@xxxxxxxxxxx> wrote:
> > 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 :)

Good.  :)

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

Thing is, it's not OK to break other subsystems like that.

> There's really no big difference between the usb drivers here and the
> disk I/O scheduler queue, AFAICT,

The disk scheduler queue is more complex, as I understand things,
since it can combine operations.  For USB, "combining" would break
essential semantics relied on by both sides of the transaction.

Maybe the best way to view this is to accept that with USB, all
scheduler operations (e.g. for bandwidth reservation management)
are out of scope of the AIO request model.  AIO requests are no
more (or less) than "append this to the endpoint's I/O queue",
with the (host side) I/O scheduling handled separately.

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

Sounds more complex, but it would be nice to have that code become
zero-copy instead of single-copy.  That'd let some platforms work
with high bandwidth ISO from userspace, which previously would not
have had enough CPU bandwidth.  ("High bandwidth" means sustained
8-24 MByte/sec data streaming.  Processing pixels at that rate may
require a companion DSP...)  Testing will be different issue though.

- Dave

<Prev in Thread] Current Thread [Next in Thread>