On Sat, 16 Apr 2005, Oliver Neukum wrote: > > The point is not whether things are interrupt-driven, it's whether or not > > interrupts are enabled. In a bottom-half handler all the time-consuming > > work can be done with interrupts enabled. > > How so? Part of the work done in IRQ can be shifted to tasklets, yes.
So can part of the work done in enqueue. > 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. In any case, I'm not concerned about optimization -- if I was I wouldn't be talking about using a bottom half. I'm concerned about reducing the amount of time spent with interrupts disabled. It's not necessary to optimize any code or improve any run times; it's necessary only to move things around so they can execute with interrupts enabled. > So instead of shifting code in the enqueue path to a different lock, > shifting it under no lock or into another path at all would seem better > to me. 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. 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
