On Mon, 23 Aug 2010, David Brownell wrote: > > Wouldn't it make more sense to have scan_periodic() > > terminate its inner > > loop whenever it encounters a Q_TYPE_QH entry? And > > then do a separate > > pass over all the interrupt QHs, much like scan_async() > > does a pass > > over all the QHs in the async ring? > > Probably better to group by period not type. Although it > should be a NOP to scan an IRQ QH that's done nothing. An expensive NOP. qh_completions() is a complex function. > No > point in skewing the timings even more, though, by adding > any type of sort-by-type. I don't follow. Can you spell this out in greater detail? My thought was just to put all the interrupt QHs on a big list, kind of like the async ring, and have scan_periodic check them all. (Or maybe split the function up into scan_isochronous and scan_interrupt, since the two activities aren't very similar.) The drawback, of course, is that we would also end up scanning QHs that _couldn't_ have made any progress because they weren't reachable from any of the frames we're looking at. A different approach that would solve this problem is to keep the current scanning code, but store in the QH the last frame it was scanned for and skip over QHs that were just scanned. > - DaveOtherwise, I think I like what you're suggesting. 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
