Re: High-priority softirqs [was: [PATCH] usb: don't offload isochronous urb completions to ksoftirq]

From: Mikulas Patocka
Date: Fri Jun 15 2018 - 17:05:10 EST

On Fri, 15 Jun 2018, Thomas Gleixner 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.
> Thanks,
> tglx

I don't think that threaded interrupt handlers are a good idea.

There are existing tools such as rtkit in Linux distributions that
increase the priority of audio applications to real time. And if rtkit
increases the priority of audio player or audio server above the priority
of the interrupt thread that handles the soundcard - sound playback is

You would have to set the priority of the interrupt thread to the highest
real-time priority - and in such a case, the interrupt thread is no
different than a hard-irq handler.