Re: [linux-usb-devel] Re: Inefficient PCI DMA usage (was:

[David Brownell]

The usb-ohci driver, widely used on non-x86 platforms, has hit
the same issue.  (Including on some ARM setups.)  An EHCI driver
(usb 2.0, 60 MByte/sec) under way has it too.

The alternative of having every device driver implement their
own simplified (?) kmem_cache code would just seem wrong; it'd
certainly be the cause of lots of bugs.  Simplest to just let
the kmem cache code reach into a different page pool, and make
drivers init their kmem caches appropriately.

I'd hope such a thing wouldn't need to wait for the 2.5 tree to
branch, since using 2.4 effectively on some non-Intel architectures
will require wider use of the pci_{alloc,free}_consistent() stuff.

- Dave

----- Original Message -----
From: Johannes Erdfelt <[e-mail]>
To: Russell King <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Saturday, January 20, 2001 9:34 AM
Subject: [linux-usb-devel] Re: Inefficient PCI DMA usage (was: [experimentalpatch] UHCI
updates)

> On Sat, Jan 20, 2001, Russell King <[e-mail]> wrote:
> > Johannes Erdfelt writes:
> > > On Fri, Jan 19, 2001, Miles Lane <[e-mail]> wrote:
> > > > Johannes Erdfelt wrote:
> > > >
> > > > > TODO
> > > > > ----
> > > > > - The PCI DMA architecture is horribly inefficient on x86 and ia64. The
> > > > >   result is a page is allocated for each TD. This is evil. Perhaps a slab
> > > > >   cache internally? Or modify the generic slab cache to handle PCI DMA
> > > > >   pages instead?
> > > >
> > > > This might be the kind of thing to run past Linus when the 2.5 tree
> > > > opens up.  Are these inefficiencies necessary evils due to workarounds
> > > > for whacky bugs in BIOSen or PCI chipsets or are they due to poor
> > > > design/implementation?
> > >
> > > Looks like poor design/implementation. Or perhaps it was designed for
> > > another reason than I want to use it for.
> >
> > Why?  What are you trying to do?  Allocate one area per small structure?
> > Why not allocate one big area and allocate from that (like the tulip
> > drivers do for their TX and RX rings)?
> >
> > I don't really know what you're trying to do/what the problem is because
> > there isn't enough context left in the original mail above, and I have
> > no idea whether the original mail appeared here or where I can read it.
>
> I was hoping the context from the original TODO up there was sufficient
> and it looked like it was enough.
>
> TD's are around 32 bytes big (actually, they may be 48 or even 64 now, I
> haven't checked recently). That's a waste of space for an entire page.
>
> However, having every driver implement it's own slab cache seems a
> complete waste of time when we already have the code to do so in
> mm/slab.c. It would be nice if we could extend the generic slab code to
> understand the PCI DMA API for us.
>
> > > I should also check architectures other than x86 and ia64.
> >
> > This is an absolute must.
>
> Not really. The 2 interesting architectures are x86 and ia64 since
> that's where you commonly see UHCI controllers. While you can add UHCI
> controllers to most any other architecture which has PCI, you usually
> see OHCI on those systems.
>
> I was curious to see if any other architectures implemented it
> differently and I was just expecting too much out of the API. You pretty
> much confirmed my suspicions when you suggested doing what the tulip
> driver does.
>
> JE
>
>
> _______________________________________________
> [e-mail]
> To unsubscribe, use the last form field at:
> http://lists.sourceforge.net/lists/listinfo/linux-usb-devel