Messages in this thread | | | Date | Tue, 12 Jun 2018 12:03:27 -0400 (EDT) | From | Mikulas Patocka <> | 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: > > > > > > > On Tue, 12 Jun 2018, Alan Stern wrote: > > > > > On Tue, 12 Jun 2018, Mikulas Patocka wrote: > > > > > > > I have a single-core machine with usb2 soundcard. When I increase mplayer > > > > priority (to real-time or high non-realtime priority), the sound is > > > > stuttering. The reason for the stuttering is that mplayer at high priority > > > > preempts the softirq thread, preventing URBs from being completed. It was > > > > caused by the patch 428aac8a81058 that offloads URB completion to softirq. > > > > > > > > This patch prevents offloading isochronous URBs to softirq to fix the > > > > stuttering. > > > > > > How about just not running mplayer at such a high priority? > > > > I need to run mplayer at a high priority so that other work doesn't > > preempt mplayer and cause stuttering. > > Think about this a little more... You _want_ the softirq thread to > preempt mplayer. Or at least, you don't want mplayer to use so much > CPU time that the softirq thread doesn't get a chance to run.
I had usb1 sound card before - and there was no problem with high-priority mplayer. I could set mplayer to real time and it played solid. Because the UHCI driver doesn't offload URB callbacks to softirq.
When I bought usb2 sound card, this problem with softirq arised. If I set it to realtime or -20, it skips, if I set it to -15, it skips less, perhaps there is some boundary between 0 and -15 where it stops skipping - but it seems quite stupid that music player skips more often with higher priority.
> > > Or raising the priority of the softirq thread? > > > > Do you want to coordinate that with the softirq maintainers? I don't know > > if they would be happy to add an extra real-time softirq thread. > > 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.
> 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?
Mikulas
| |