On Fri, 25 Jan 2013, Piergiorgio Sartor wrote: > Hi Alan, > > I tested the kernel with the latest patch you provide. > > I was not able to reproduce the problem, so it seems > this change is fine. Okay, good. I'll submit this for inclusion in the stable kernels. > The only comment I've is that I'm under the impression > that unlinking multiple queue element together was > giving a slightly better perfomance, under certain > trafic conditions (when working). That's hard to analyze. It involves a complex tradeoff. Leaving a QH on the schedule when it doesn't have any work to do causes the controller to perform unnecessary DMA accesses, putting pressure on the the PCI and memory buses. This pressure isn't all that high, but there's no point allowing it to continue indefinitely. On the other hand, unlinking a QH from the schedule involves a certain amount of work for the CPU, and unlinking a bunch of them at once is a little less work than doing them one at a time. Unlinking a QH also prevents that QH from being used again until the unlink is completely finished, which could delay the next I/O operation. Hence we don't want to unlink a QH until we have some indication that it won't be used again for a while, i.e., until it has been empty for some minimum time. Delaying the unlink actually could improve performance in cases where the QH _is_ about to be used again. Finally, multiple unlinks turn out to be relatively rare events. In your testing, however, all those concurrent accesses to multiple disks do tend to make opportunities for multiple unlinks more frequent. So in the end, I don't know. The difference probably isn't big enough to worry about or to bother anybody. Also, it's how the driver used to work (more or less up until the commit that you identified in your bisection). > I guess, if you're confident the code does not have > other different issues, you can push it upstream. > > Thanks again for the support, You're welcome. 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
