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:   Tue, 12 Jun 2018 12:03:27 -0400 (EDT)
From:   Mikulas Patocka <mpatocka@redhat.com>
To:     Alan Stern <stern@rowland.harvard.edu>,
        Ming Lei <ming.lei@redhat.com>
cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Ming Lei <ming.lei@canonical.com>, linux-usb@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: don't offload isochronous urb completions to
 ksoftirq
In-Reply-To: <Pine.LNX.4.44L0.1806121108350.1582-100000@iolanthe.rowland.org>
Message-ID: <alpine.LRH.2.02.1806121145040.26084@file01.intranet.prod.int.rdu2.redhat.com>
References: <Pine.LNX.4.44L0.1806121108350.1582-100000@iolanthe.rowland.org>
User-Agent: Alpine 2.02 (LRH 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


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