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 ? -- balbi
Attachment:
signature.asc
Description: PGP signature
