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 16:54:14 -0400 (EDT)
From:   Alan Stern <stern@rowland.harvard.edu>
To:     Sebastian Sewior <bigeasy@linutronix.de>
cc:     Steven Rostedt <rostedt@goodmis.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Mikulas Patocka <mpatocka@redhat.com>,
        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>
Subject: Re: High-priority softirqs [was: [PATCH] usb: don't offload isochronous
 urb completions to ksoftirq]
In-Reply-To: <20180615174012.m6rqow2sytwgxxrx@linutronix.de>
Message-ID: <Pine.LNX.4.44L0.1806151649060.1387-100000@iolanthe.rowland.org>
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, 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@linutronix.de> 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.
> 
>  https://lkml.kernel.org/r/20180216170450.yl5owfphuvltstnt@breakpoint.cc

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.

Alan Stern