Thread (66 messages) 66 messages, 6 authors, 2013-06-15
STALE4755d
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 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 [diff vs 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-12 14:35:44

On Wed, 12 Jun 2013, Ming Lei wrote:
If not, I am wondering why one USB driver need register another hard
interrupt handler? Could you share such examples? I understand the
case only exists with timer handler as discussed with Oliver, don't I?
Here's another possibility.  A USB driver has a private lock, and it
acquires this lock in its completion handler.  But it also acquires
this lock in other routines, and those other routines may be called by
other drivers or subsystems in interrupt context.
quoted
The drivers _do_ need to be changed, as explained above.  And that
explanation was only one failure scenario.  There may be others.
OK, I'd like to know what the others are? :-)
Me too.  :-)
quoted
quoted
And finally, USB HCDs themselves will benefit from the change, won't they?
How will they benefit?  Merely from not releasing their private locks?
The interrupt of one HCD will be responded lately since another HCD's
interrupt handler takes very long time. With the change, the problem can
be avoided.
For reasonably sophisticated host controllers like EHCI, the delay in
responding to an interrupt doesn't matter much.  But for simpler host
controllers (for example, those using PIO instead of DMA) it matters
more, so those other HCDs will benefit more from the conversion.
quoted
quoted
Compared with "usb-storage" task's schedule latency, the tasklet
schedule delay should be lower at most of situations since the tasklet
is scheduled inside irq handler.
True.  But the two latencies add.
I think it should be one tasklet latency added, but what is the other one?
I meant that the latency in tasklet scheduling has to be added to the 
latency in scheduling the usb-storage thread.
quoted
Or you could have a separate tasklet for each host controller.
Yes, but I will compare tasklet with interrupt threaded handler first.
Switching to a threaded interrupt handler offers more possibilities.  
Instead of moving just the givebacks to the thread, we could put almost 
all the processing there.  (At least, we can for ehci-hcd.  Other HCDs 
may not be able to do this.)

At this point we are talking about multiple changes:

	Moving the givebacks to a tasklet or threaded handler.

	Changing the USB completion handlers so that they can be called 
	with interrupts enabled.	

	Allowing the tasklet/thread to run with interrupts enabled.

	Moving more of the HCD processing into the tasklet/thread.

Maybe other things too.  In principle, the first and second items can 
be done simultaneously.

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