On Sun, 17 Apr 2005, Oliver Neukum wrote: > > A tasklet can be useful for another reason. Consider that even if an IRQ > > handler does run with interrupts enabled, its own IRQ line still has to > > remain disabled. So any devices sharing the IRQ line are unable to > > interrupt the CPU until the handler finishes. With a tasklet, the handler > > finishes much sooner. > > True, but relvant only for irq handlers.
So you agree that it might make sense to move uhci_irq to a tasklet, since it _is_ an IRQ handler? > > There are reasons for not enabling interrupts other than being in hard irq > > context: > > > > You want to modify a data structure that other interrupt-time > > code also touches, so you don't want other interrupts to > > occur until you have finished the modifications. (This applies > > just as well to code that's not in an interrupt handler. You > > can think of this as a locking-related reason.) If that other > > code can be moved into a tasklet, you win. > > Exactly. If the _other_ code can be moved to a tasklet. The other > code in question here is the irq handler. Leaving interrupts on > in the task context code is achieved by using spin_lock_bh(). >From the point of view of enqueue, the other code is dequeue and uhci_irq. >From the point of view of uhci_irq, the other code is enqueue and dequeue. None of the three runs in process context, in general. Using spin_lock_bh() in enqueue or dequeue isn't a solution because existing code already calls these routines with interrupts disabled. > > Your caller has disabled interrupts and expects you to leave > > them disabled. If you defer most of your work to a tasklet > > and return sooner, you win. > > > > All of these reasons apply to uhci-hcd. > > So convert irq handling to tasklets. There's no point as long as enqueue and dequeue can run at interrupt time. They have to be moved to the tasklet also. > > > If you shift the existing enqueue code to a tasklet > > > you gain nothing, because the spinlocks need to block irqs. > > > > You're assuming that the tasklet needs to acquire the same spinlock as the > > existing code and for the same length of time. If you shift the enqueue > > code to a tasklet and make the tasklet avoid the spinlock as much as > > possible, then you do gain something. > > You gain what you gain by avoiding the spinlock. Being in a tasklet doesn't > help. But it's not possible to avoid the spinlock unless all the code (enqueue, dequeue, and uhci_irq) is moved to a single tasklet. > Using a single tasklet for multiple tasks is unbelievably ugly. One might claim that using an IRQ handler for multiple tasks is also unbelievably ugly. Nevertheless much (or even most) of what an HCD does takes place in its IRQ handler, so the ugliness is already there. This won't make it much worse. Besides, it's all a question of whether or not activities count as being part of the same task. In this case we can say that the tasklet is charged with managing the controller's hardware schedule. Thus taking care of enqueue, dequeue, and IRQs are really all one task. :-) Alan Stern ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
