Re: [linux-usb-devel] PATCH: Don't allocate transfer buffersonthestackin hub.c
On Thu, 5 Jun 2003, Oliver Neukum wrote:
extern inline dma_addr_t pci_map_single(struct pci_dev *hwdev, void *ptr,
size_t size, int direction)
{
if (direction == PCI_DMA_NONE)
BUG();
#ifndef CONFIG_COHERENT_IO
dma_cache_wback_inv((unsigned long)ptr, size);
#endif
return virt_to_bus(ptr);
}
It is probably best to allocate all buffers seperately.
I don't follow you. What's inefficient about this? It looks like the
decision of whether or not to call dma_cache_wback_inv() has nothing to do
with what other data is stored in the same memory block with the output
buffer. And there's nothing that indicates dma_cache_wback_inv() is less
efficient when ptr isn't aligned on a cacheline.
No, I meant sharing it. You'd get a full hard cache miss.
I get it. The writeback-and-invalidate means that the next time the CPU
tries to access any data in that region of memory it must wait for the
cache to fill up. And apparently the MIPS doesn't support writeback
without invalidating, which would make more sense for DMA_OUT operations.
So your point that output buffers shouldn't share memory regions is well
taken.
On the other hand, for DMA_IN it is most likely that the next piece of
data the CPU will access in that memory region is the input buffer itself.
Especially if the memory region is devoted only to input buffers and the
input operations occur sequentially. So nothing is lost by incurring a
cache miss there, because the CPU would have to refill its cache anyway.
Alan Stern
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
RE: [linux-usb-devel] PATCH: Don't allocate transfer buffersonthestackin hub.c
So all I/O buffers _must_ be allocated using kmalloc() Use GFP_DMA flag on the kmalloc() call, too, whenever possible. /* Flag - indicates that the buffer will be suitable for DMA. Ignored on some platforms, used as appropriate on others */ #define GFP_DMA __GFP_DMA This will help avoid bounce buffering on some systems. -ch --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] PATCH: Don't allocate transfer buffersonthestackin hub.c
From: Christopher Hoover [EMAIL PROTECTED] Date: Fri, 6 Jun 2003 10:58:50 -0700 So all I/O buffers _must_ be allocated using kmalloc() Use GFP_DMA flag on the kmalloc() call, too, whenever possible. This will help avoid bounce buffering on some systems. Wrong!!! Where did you get this idiotic idea? NEVER use GFP_DMA if you can help it. It allocates from zone[0] and creates pressure on it. -- Pete P.S. For the record, GFP_DMA is needed when a device does not have enough addressing capability to reach normal memory _and_ there is no MMU in the picture. Thus, it's a short list: 1. Non-busmastering DMA for ISA devices on x86 2. CCW on s390 (but not IDALs) 3. SAC PCI DMA on Itanic with no MMU, such as SGI SN-2 This is _it_! No more cases to use GFP_DMA! --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
