On Fri, 14 Jun 2013, Alan Stern wrote:
> On Fri, 14 Jun 2013, Ming Lei wrote:
>
> > >> With the two trace points of irq_handler_entry and irq_handler_exit, the
> > >> interrupt latency(or the time taken by hard irq handler) isn't hard to
> > >> measure.
> > >> One simple script can figure out the average/maximum latency for one irq
> > >> handler, like I did in 4/4.
> > >
> > > But that doesn't measure the time between when the IRQ request is
> > > issued and when irq_handler_entry runs.
> >
> > That might be hard to measure, also I am wondering if the time can be
> > measured only by software, but these patches only focus on the time
> > between HCD irq entry and irq exit.
>
> Not entirely. On a UP system, leaving interrupts disabled for a long
> time (which is what we do now) increases the delay between when the IRQ
> is raised and when it is serviced. On an SMP system, a long-running
> interrupt handler will delay servicing a different device that shares
> the same IRQ line.
And on UP it delays ALL other interrupts. I've seen 500us+ caused by
the USB interrupt handlers...
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
