Re: High-priority softirqs [was: [PATCH] usb: don't offload isochronous urb completions to ksoftirq]
From: Alan Stern
Date: Fri Jun 15 2018 - 16:54:20 EST
On Fri, 15 Jun 2018, Sebastian Sewior wrote:
> On 2018-06-15 13:34:28 [-0400], Steven Rostedt wrote:
> > On Fri, 15 Jun 2018 19:28:34 +0200 (CEST)
> > Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> > > One solution to that is to avoid both tasklets and kworkers and change the
> > > USB code to make use of threaded interrupt handlers. I.e. handle the fast
> > > stuff in the primary (hardirq) handler and delegate the rest to the irq
> > > thread. That thread still can offload disk type stuff to a kworker if
> > > needed. But the irq thread allows to bring the stuff under scheduler
> > > control and experiments which I did a few years ago worked out pretty good.
> > If there's any question about this, drivers can request to have their
> > interrupt handlers run as threads. This has been added to mainline
> > years ago. And it really should be the default solution before pushing
> > off to tasklets or kworkers.
This is more or less independent of our original question. Even if we
migrate the USB stack to use threaded interrupt handlers instead of
tasklets, we still have to face the issue of completing some
isochronous URBs at high priority and others not in interrupt context
(presumably at normal priority).
The URB_FAST_COMPLETION approach seems like the best solution to the
audio problem. And if we do switch over to threaded interrupts for URB
completions in the future, it should still be compatible.