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