2010/8/24 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>: > 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. Scaning each QH only once in scan_periodic is enough, so it is not difficult to give the implementation. -- Lei Ming -- 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
