lkml.org 
[lkml]   [2001]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [linux-usb-devel] Re: Inefficient PCI DMA usage (was: [experimentalpatch] UHCI updates)
    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 <johannes@erdfelt.com>
    To: Russell King <rmk@arm.linux.org.uk>
    Cc: <linux-kernel@vger.kernel.org>; <linux-usb-devel@lists.sourceforge.net>
    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 <rmk@arm.linux.org.uk> wrote:
    > > Johannes Erdfelt writes:
    > > > On Fri, Jan 19, 2001, Miles Lane <miles@megapathdsl.net> 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
    >
    >
    > _______________________________________________
    > linux-usb-devel@lists.sourceforge.net
    > To unsubscribe, use the last form field at:
    > http://lists.sourceforge.net/lists/listinfo/linux-usb-devel

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:02    [W:0.037 / U:31.640 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site