On Sat, 16 Apr 2005, Oliver Neukum wrote:

> > > But the enqueue times are worse, so are in more need of optimisation.
> > 
> > Although enqueue took more time than IRQ handling on average, I'm more
> > concerned about maximum times.  Enqueue's maximum time was worse on one of
> > the computers, IRQ handling's was worse on the other.
> 
> But enqueuing in many drivers is part of irq handling. Storage is an
> exception in that regard.

Yes, I only ran one sort of test.  Testing with a different device would
undoubtedly give different results.  Anyway, moving most of the work from
enqueue to the tasklet would certainly improve enqueue's running time!


> > Who said anything about a different lock?  The tasklet approach will shift 
> > enqueue code to run in the tasklet, which means it automatically benefits 
> > from the kernel's policy of allowing only one instance of a tasklet to run 
> > at any time.  Anyway, locks aren't the issue -- interrupt enabling is.
> 
> What is the point of using a tasklet? It is about locking, not context.

No!  Just the reverse.  The point of using a tasklet has nothing to do
with locking.  It is about running time-consuming code in an
interrupt-enabled context.  That's why bottom halves were invented in the
first place -- so that lengthy I/O handlers could run without blocking
interrupts.

> Using a tasklet from task context is never sensible. Either you need
> interrupts off, or you don't need them off. Needing to take a spinlock
> in a tasklet doesn't help. Task context is already lower in priority.

What does this have to do with what I've been talking about?  I've
described how a tasklet could be used by the IRQ handler (clearly not in
process context) and by enqueue/dequeue (which might or might not be
called in process context, so we have to assume they aren't).  I'm not
planning on holding a spinlock within the tasklet, except at a few
specific spots.

> In addition, usb_submit_urb() must work from hard irq context.

Yes.

> You need to to do anything than can error before you kick off a
> tasklet,

No.  It's okay to return an error by completing an URB with ->status set 
appropriately.

>  and you must make sure that usb_unlink_urb() will work
> before the tasklet runs.

I will make sure of that.

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