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

Reply via email to