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 19:28:34 +0200 (CEST)
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Alan Stern <stern@rowland.harvard.edu>
cc:     Mikulas Patocka <mpatocka@redhat.com>,
        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: <Pine.LNX.4.44L0.1806151308310.1387-100000@iolanthe.rowland.org>
Message-ID: <alpine.DEB.2.21.1806151919130.1582@nanos.tec.linutronix.de>
References: <Pine.LNX.4.44L0.1806151308310.1387-100000@iolanthe.rowland.org>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
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, Alan Stern wrote:
> On Fri, 15 Jun 2018, Mikulas Patocka wrote:
> 
> > I think the major problem (in the upstream kernel) with softirq latency is 
> > this:
> > static inline void invoke_softirq(void)
> > {
> >         if (ksoftirqd_running())
> >                 return;
> > 
> > It means that if any piece of code kicks ksoftirq, no tasklets are 
> > processed in the irq context at all.
> > 
> > So, the ehci callbacks will be offloaded to ksoftirqd (no matter how small 
> > they are) and this causes audio skipping. Could this be changed, so that 
> > it processes tasklets submitted with "tasklet_hi_schedule" in irq context 
> > even if ksoftirqd is running?
> 
> That's a great question.  Basically you're asking to have the HI 
> softirq always handled in the bottom half, never in ksoftirqd, right?  
> 
> Or maybe to have more than one softirq thread, to handle different 
> softirq levels, so that they can be assigned differing priorities.
> 
> > It's not easy - __do_softirq lacks any locking - so it can't run 
> > concurrently in process context and in irq context.
> 
> I have no idea.  Maybe someone with a better understanding of this part
> of the kernel can help.

Well, yes. Similar issues have been discussed in the past, but softirqs and
especially tasklets have horrible semantics. There was an attempt to deal
with that, but that didn't end well.

There is another even worse issue with USB/audio which I looked at a few
days ago. Some USB hosts offload to kworkers, which has even worse
behaviour than the ksoftirqd case.

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