On Fri, 16 Feb 2018, Sebastian Andrzej Siewior wrote: > I've been going over Frederic's softirq patches and it seems that there > were two problems. One was network related, the other was Mauro's USB > dvb-[stc] device which was not able to stream properly over time. > > Here is an attempt to let the URB complete in the threaded handler > instead of going to the tasklet. In case the system is SMP then the > patch [0] would be required in order to have the IRQ and its thread on > the same CPU. > > Mauro, would you mind giving it a shot? > > [0] genirq: Let irq thread follow the effective hard irq affinity > https://git.kernel.org/tip/cbf8699996a6e7f2f674b3a2a4cef9f666ff613e > > --- > > The urb->complete callback was initially invoked in IRQ context after > the HCD dropped its lock because the callback could re-queue the URB > again. Later this completion was deferred to the tasklet allowing the > HCD hold the lock. Also the BH handler can be interrupted by the IRQ > handler adding more "completed" requests to its queue. > While this batching is good in general, the softirq defers its doing for > short period of time if it is running constantly without a break. This > breaks some use cases where constant USB throughput is required. > As an alternative approach to tasklet handling, I defer the URB > completion to the HCD's threaded handler. There are two lists for > "high-prio" proccessing and lower priority (to mimic current behaviour). > The URBs in the high-priority list are always preffered over the URBs > in the low-priority list. We originally used tasklets because we didn't want to incur the delays associated with running in a process context. It seems odd to be reversing that decision now. > The URBs from the root-hub never create an interrupt so I currently > process them in a workqueue (I'm not sure if an URB-enqueue in the > completion handler would break something). It worked okay before we changed over to using tasklets. Alan Stern -- 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
