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