On Tue, 17 Nov 2015, Markus Rechberger wrote: > There are 2 problems with the current implementation: > > 1. the memset on isochronous transfers to empty the buffers in order > to avoid leaking raw memory to userspace (this costs a lot on intel > Atoms and is also noticeable on other systems). It won't be necessary if we can directly map the user-provided buffer for DMA. But if we have to use a bounce buffer, we have to do something about it. In theory we could avoid the memset by only copying back to userspace the memory that was written to. > 2. the memory fragmentation. Seems like recent systems have a better > performance here since we did not get that report for several months > now, or maybe the user behavior changed. > Some older Linux systems (maybe 2-3 years old) triggered this issue > way more often. Again, this is a problem only if a bounce buffer is needed. On the other hand, bounce buffers might be common on systems with more than 4 GB of memory, if the host controller can only do 32-bit DMA. On the other hand, adding an API that allows users to allocate low memory and then hiding it in the USB subsystem doesn't seem like a good idea. > The CPU usage decreases 1-2% on my 1.3ghz U7300 notebook > The CPU usage decreases 6-8% on an Intel Atom n270 when > transferring 20mbyte/sec (isochronous), it should be more interesting to > see those > statistics on embedded systems (eg. some older MIPS systems) where > copying data is more expensive. > > I would not count on IOMMU in that case because several systems which > should take benefit of a change in that area simply do not support > IOMMU. If those systems don't have more than 4 GB of memory then it won't matter. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
