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 audio. In my opinion, it is much easier to fix this in the ehci driver (by not offloading isochronous completions), than to design a new real-time-capable ksoftirqd. > > > 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? Mikulas -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
