Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 15 Jun 2018 17:05:01 -0400 (EDT)
From:   Mikulas Patocka <mpatocka@redhat.com>
To:     Thomas Gleixner <tglx@linutronix.de>
cc:     Alan Stern <stern@rowland.harvard.edu>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ming Lei <ming.lei@redhat.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        USB list <linux-usb@vger.kernel.org>,
        Kernel development list <linux-kernel@vger.kernel.org>,
        Sebastian Sewior <bigeasy@linutronix.de>
Subject: Re: High-priority softirqs [was: [PATCH] usb: don't offload isochronous
 urb completions to ksoftirq]
In-Reply-To: <alpine.DEB.2.21.1806151919130.1582@nanos.tec.linutronix.de>
Message-ID: <alpine.LRH.2.02.1806151658000.24974@file01.intranet.prod.int.rdu2.redhat.com>
References: <Pine.LNX.4.44L0.1806151308310.1387-100000@iolanthe.rowland.org> <alpine.DEB.2.21.1806151919130.1582@nanos.tec.linutronix.de>
User-Agent: Alpine 2.02 (LRH 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


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 
screwed.

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.

Mikulas