On Thu, Apr 21, 2016 at 01:56:58PM +0300, Felipe Balbi wrote: > > Hi, > > Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx> writes: > > Hi, > > > > Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> writes: > >> On Mon, Apr 11, 2016 at 03:44:09PM +0300, Felipe Balbi wrote: > >>> Hi guys, > >>> > >>> this patchset introduces support for threaded IRQs > >>> for host controllers drivers to use. Right now, only > >>> XHCI has been converted, but more drivers could > >>> easily be converted as well. > >>> > >>> With this series we can, eventually, spend much less > >>> time with IRQs disabled. Note that, because we're > >>> masking XHCI's IRQs, we could run our thread > >>> handlers with IRQs enabled, but I haven't tested > >>> that yet. > >> > >> Does it really benifit anything? Do you have any measurements? Why the > > > > I have measurements showing that it doesn't have a negative impact. > > > >> added work for no real need, and increased latency? > > > > the latency is negligible. XHCI's irqs are used for completions and > > aborts, not to start transfers. Also, it's a generally a good idea to > > spend less time in hardirq context. Not to mention that this is a good > > stepping stone for further optimization; we could (and probably should) > > have a per-device-slot irq thread and also per-device-slot locks and > > demote the controller's lock to only the parts which actually need to > > access controller-wide resources (for the most part we have > > slot-specific registers, anyway). > > > > Now, the benefit of the work yet to come is that we could be processing > > N slots concurrently given we have N cpu cores. > > > > Note, also, that we're not forcing anybody to use this but given that > > XHCI has these separate units referred to as 'device slots', we might as > > well exploit that, right ? > > Any further comments here ? Greg ? Mathias ? I'm traveling this week, will get to them next week, sorry... greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
