Re: [PATCH] usb: don't offload isochronous urb completions to ksoftirq
- Date: Tue, 12 Jun 2018 13:19:28 -0400 (EDT)
- From: Mikulas Patocka <mpatocka@xxxxxxxxxx>
- Subject: Re: [PATCH] usb: don't offload isochronous urb completions to ksoftirq
On Tue, 12 Jun 2018, Alan Stern wrote:
> On Tue, 12 Jun 2018, Mikulas Patocka wrote:
> > > How about making the softirq thread's priority adjustable?
> > But you would have to argue with softirq maintainers about it - and you
> > say that you don't have time for that.
> But maybe _you_ do...
ksoftirqd has priority 0 - it is not suitable for real-time tasks, such as
In my opinion, it is much easier to fix this in the ehci driver (by not
offloading isochronous completions), than to design a new
> > > As for coordinating with the softirq maintainers -- whether I want to
> > > or not isn't the issue. Right now I don't have _time_ to do it.
> > >
> > > Alan Stern
> > I am wondering - whats the purpose of that patch
> > 428aac8a81058e2303677a8fbf26670229e51d3a at all? The patch shows some
> > performance difference, but they are minor, about 1%.
> > If you want to call the urb callback as soon as possible - why don't you
> > just call it? Why do you need to offload the callback to a softirq thread?
> Please read the Changelog entry for commit 94dfd7edfd5c. Basically the
> idea was to reduce overall latency by not doing as much work in an
> interrupt handler.
> Alan Stern
snd_complete_urb is doing nothing but submitting the same urb again. Is
resubmitting the urb really causing so much latency that you can't do it
in the interrupt handler?