Thread (66 messages) 66 messages, 6 authors, 2013-06-15
STALE4754d
Revisions (16)
  1. rfc [diff vs current]
  2. rfc [diff vs current]
  3. rfc [diff vs current]
  4. rfc [diff vs current]
  5. rfc [diff vs current]
  6. rfc [diff vs current]
  7. rfc [diff vs current]
  8. rfc [diff vs current]
  9. rfc [diff vs current]
  10. rfc [diff vs current]
  11. rfc [diff vs current]
  12. rfc [diff vs current]
  13. rfc [diff vs current]
  14. rfc [diff vs current]
  15. rfc current
  16. v3 [diff vs current]

[RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context

From: stern@rowland.harvard.edu (Alan Stern)
Date: 2013-06-14 20:23:20

On Fri, 14 Jun 2013, Ming Lei wrote:
quoted
quoted
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.

Alan Stern
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help