> Presumably this is from the CPU trace port, OMAP3 with NO_HZ. Yes. Just using git-latest kernel and NO_HZ. You can get the same data on OMAP2 also through ETM. I don't see much profiling on the 'live' tree here. Internal trees at TI generally get looked at more critically. It might be interesting to compare. > Do I read this right: 18 usec tick processing overhead after > receiving an IRQ, before even getting to the generic OMAP GPIO > irq logic (which then has to dispatch to the real IRQ handler)? > Over 5 usec just for updating jiffies64 ... I've not calibrated to verify but that seems to be what the picture is showing so there is some chance the time base is off. All the instruction trace is there to walk it if necessary. There have been some comments about NO_HZ adding some overhead from those who measure MHz around here for things like MP3 load models. I hadn't looked very closely. I suppose this might be an ether interrupt. If it were just a timer interrupt it shouldn't need to make its way to the GPIO handler. Trace does give a unique view into the system which is hard to get otherwise. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
