On Tue, 28 Apr 2009, Sarah Sharp wrote: > > I'm a bit curious why you wouldn't add all this statistics code > > to usbcore, instead of modifying each HCD. You've already got > > single access points for submit and giveback paths; and doing it > > in usbcore would provide much more consistent measurements. > > I wanted a way to measure the hardware performance, minus any software > overhead for giving back the URBs, drivers resubmitting, etc. I wanted > the finished timestamp for the URB to be as close as possible to the > time of the hardware interrupt, so there had to be unique code for each > HCD. I also wanted to make it generic enough that you could measure the > overhead of different parts of the USB software stack. It's worth mentioning that for most of the HCDs, the generic interrupt handler in usbcore (i.e., usb_hcd_irq() in hcd.c) gets called before any HCD-specific code. It is therefore closer to the actual hardware interrupt. However, I have to agree with David on this. If you're trying to measure raw hardware performance then you probably should use a hardware bus analyzer instead of instrumenting the kernel. If you're trying to measure overall hardware+driver performance, then measurements made inside usbcore are more relevant than measurements from within the HCD. The "overhead of different parts of the USB stack" is a slippery concept. To some extent you're better measuring that from within a higher-level driver. For instance, how long does a single call of usb_submit_urb() take? That time is entirely overhead, and it should be measured from within the caller. 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
