Inefficient PCI DMA usage (was: [experimental patch] UHCI updates)
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines · Miles Lane
Quoted 6 lines · Johannes Erdfelt
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?
Quoted 4 lines
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.
2.5 is probably where any core changes will happen, if any. But for now I suspect I'll need to workaround it in my driver.
I should also check architectures other than x86 and ia64.
JE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 10 lines · Johannes Erdfelt
Quoted 9 lines · Miles Lane
Quoted 6 lines · Johannes Erdfelt
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?
Quoted 7 lines
Quoted 4 lines
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.
Quoted 1 line
I should also check architectures other than x86 and ia64.
This is an absolute must.
_____
|_____| ------------------------------------------------- ---+---+- | | Russell King [email protected] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ ------------------------------------------------- /\\\ |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 19 lines · Russell King
Quoted 10 lines · Johannes Erdfelt
Quoted 9 lines · Miles Lane
Quoted 6 lines · Johannes Erdfelt
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?Quoted 7 lines
Quoted 4 lines
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.
Quoted 7 lines
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.
Quoted 3 lines
Quoted 1 line
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] Re: Inefficient PCI DMA usage (was: [experimentalpatch] UHCI updates)
In reply to Johannes ErdfeltThe 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 <[email protected]>
To: Russell King <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: Saturday, January 20, 2001 9:34 AM
Subject: [linux-usb-devel] Re: Inefficient PCI DMA usage (was: [experimentalpatch] UHCI updates)
Quoted 53 lines · Russell King
Quoted 19 lines
Quoted 10 lines · Johannes Erdfelt
Quoted 9 lines · Miles Lane
Quoted 6 lines · Johannes Erdfelt
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?Quoted 7 lines
Quoted 4 lines
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.
Quoted 7 lines
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.Quoted 3 lines
Quoted 1 line
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.
Quoted 7 lines
JE
_______________________________________________
[email protected]
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/