On Sat, Mar 16, 2013 at 10:34:43PM +0200, Anonymous wrote: > On 16/03/2013 10:15 PM, Greg KH wrote: > >Look at the data on the wire, and notice all of the delay and gaps that > >could have been filled with real data, but the protocol involved here > >(the "old" usb storage spec) prevents the full use of the xhci > >controller. > > > >Now if you actually were able to keep the host controller busy, then I > >would guess that the snooping option might actually be noticeable. But > >until you can do that, you can't even see it in the measurements, right? > > Snooping is not something that happens on the USB bus. It happens > between the memory controller and processor caches. Doing the > buffer flush in software does not reduce the load on the memory > sub-system, it just reorders its work in time - as well as creating > processor load to issue the clflush instructions. If you believe > the xHC can max out its upstream PCI express bandwidth, then it's > going to be affected by the buffer flush either way. If the buffer > is flushed by the snooping mechanism - the PCIe lane may be delayed > while the xHC is transferring packet N. If the processor flushes > buffer for packet N earlier, then the xHC may be delayed while > transmitting packet N-1. There's no reason for believing that in a > long sustained transfer anything can be gained by this reordering. Great, then you answered your own question. But if you go back to look at your first email, I think you are really confused here about what you are trying to do, so you might want to start over in your calculations. good luck, greg k-h -- 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
