From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: usb: don't offload isochronous urb completions to ksoftirq From: Greg Kroah-Hartman Message-Id: <20180612175242.GA12855@kroah.com> Date: Tue, 12 Jun 2018 19:52:42 +0200 To: Mikulas Patocka Cc: Alan Stern , Ming Lei , USB list , Kernel development list List-ID: T24gVHVlLCBKdW4gMTIsIDIwMTggYXQgMDE6MTk6MjhQTSAtMDQwMCwgTWlrdWxhcyBQYXRvY2th IHdyb3RlOgo+IAo+IAo+IE9uIFR1ZSwgMTIgSnVuIDIwMTgsIEFsYW4gU3Rlcm4gd3JvdGU6Cj4g Cj4gPiBPbiBUdWUsIDEyIEp1biAyMDE4LCBNaWt1bGFzIFBhdG9ja2Egd3JvdGU6Cj4gPiAKPiA+ ID4gPiBIb3cgYWJvdXQgbWFraW5nIHRoZSBzb2Z0aXJxIHRocmVhZCdzIHByaW9yaXR5IGFkanVz dGFibGU/Cj4gPiA+IAo+ID4gPiBCdXQgeW91IHdvdWxkIGhhdmUgdG8gYXJndWUgd2l0aCBzb2Z0 aXJxIG1haW50YWluZXJzIGFib3V0IGl0IC0gYW5kIHlvdSAKPiA+ID4gc2F5IHRoYXQgeW91IGRv bid0IGhhdmUgdGltZSBmb3IgdGhhdC4KPiA+IAo+ID4gQnV0IG1heWJlIF95b3VfIGRvLi4uCj4g Cj4ga3NvZnRpcnFkIGhhcyBwcmlvcml0eSAwIC0gaXQgaXMgbm90IHN1aXRhYmxlIGZvciByZWFs LXRpbWUgdGFza3MsIHN1Y2ggYXMgCj4gYXVkaW8uCj4gCj4gSW4gbXkgb3BpbmlvbiwgaXQgaXMg bXVjaCBlYXNpZXIgdG8gZml4IHRoaXMgaW4gdGhlIGVoY2kgZHJpdmVyIChieSBub3QgCj4gb2Zm bG9hZGluZyBpc29jaHJvbm91cyBjb21wbGV0aW9ucyksIHRoYW4gdG8gZGVzaWduIGEgbmV3IAo+ IHJlYWwtdGltZS1jYXBhYmxlIGtzb2Z0aXJxZC4KCk9rLCBidXQgd2hhdCBoYXBwZW5zIHdoZW4g eW91IHBsdWcgeW91ciBkZXZpY2UgaW50byBhIHhoY2kgY29udHJvbGxlcj8KRG8gd2UgYWxzbyBu ZWVkIHRvIGNoYW5nZSB0aGF0PyAgT25seSB0b3VjaGluZyBhIHNwZWNpZmljIGhvc3QKY29udHJv bGxlciBpcyBub3QgZ29vZCwgeW91IHdpbGwgYmUgcGxheWluZyAid2hhY2sgYSBtb2xlIiBmb3Ig Zm9yZXZlci4KCklzb2MgcGFja2V0cyBhcmUsIGJ5IGRlZmluaXRpb24sIG5vdCBzdXBwb3NlZCB0 byBiZSBndWFyYW50ZWVkIGF0IGFsbC4KU28gaWYgdGhleSBhcmUgInNsb3ciIG9yIGRyb3BwZWQg b3IgZGVsYXllZCBzb21laG93LCB0aGF0J3MgZmluZS4gIFRoZQpzb3VuZCBwcm90b2NvbCBzaG91 bGQgYmUgZmluZSB3aXRoIGl0LgoKTm93IHllcywgaW4gcmVhbGl0eSwgYXMgeW91IGhhdmUgZm91 bmQgb3V0LCB0aGluZ3MgY2FuIGJlICJ0aWdodCIgb24KbG93LXBvd2VyZWQgcHJvY2Vzc29ycyB1 bmRlciBoZWF2eSBsb2FkLiAgQnV0IHdoYXQgeW91IGFyZSBkb2luZyBoZXJlIGlzCmEgcHJpb3Jp dHkgaW52ZXJzaW9uLiAgWW91IGRvIG5vdCBzb2x2ZSBzdWNoIGEgdGhpbmcgYnkgZ29pbmcgYXJv dW5kIGFuZApyYWlzaW5nIGV2ZXJ5dGhpbmcgZWxzZSB1cCBhcyB3ZWxsLCB0aGlzIGlzIHN1cHBv c2VkIHRvIGJlIGEgImdlbmVyYWwKcHVycG9zZSIga2VybmVsLiAgWW91IGNhbiB0dW5lIGEgc3Bl Y2lmaWMgbWFjaGluZS9kZXZpY2UganVzdCBmaW5lIHRoaXMKd2F5LCBidXQgbm90IGJ5IG1lc3Np bmcgd2l0aCB0aGUga2VybmVsIGZvciB0aGUgbW9zdCBwYXJ0LgoKPiA+ID4gPiBBcyBmb3IgY29v cmRpbmF0aW5nIHdpdGggdGhlIHNvZnRpcnEgbWFpbnRhaW5lcnMgLS0gd2hldGhlciBJIHdhbnQg dG8gCj4gPiA+ID4gb3Igbm90IGlzbid0IHRoZSBpc3N1ZS4gIFJpZ2h0IG5vdyBJIGRvbid0IGhh dmUgX3RpbWVfIHRvIGRvIGl0Lgo+ID4gPiA+IAo+ID4gPiA+IEFsYW4gU3Rlcm4KPiA+ID4gCj4g PiA+IEkgYW0gd29uZGVyaW5nIC0gd2hhdHMgdGhlIHB1cnBvc2Ugb2YgdGhhdCBwYXRjaCAKPiA+ ID4gNDI4YWFjOGE4MTA1OGUyMzAzNjc3YThmYmYyNjY3MDIyOWU1MWQzYSBhdCBhbGw/IFRoZSBw YXRjaCBzaG93cyBzb21lIAo+ID4gPiBwZXJmb3JtYW5jZSBkaWZmZXJlbmNlLCBidXQgdGhleSBh cmUgbWlub3IsIGFib3V0IDElLgo+ID4gPiAKPiA+ID4gSWYgeW91IHdhbnQgdG8gY2FsbCB0aGUg dXJiIGNhbGxiYWNrIGFzIHNvb24gYXMgcG9zc2libGUgLSB3aHkgZG9uJ3QgeW91IAo+ID4gPiBq dXN0IGNhbGwgaXQ/IFdoeSBkbyB5b3UgbmVlZCB0byBvZmZsb2FkIHRoZSBjYWxsYmFjayB0byBh IHNvZnRpcnEgdGhyZWFkPwo+ID4gCj4gPiBQbGVhc2UgcmVhZCB0aGUgQ2hhbmdlbG9nIGVudHJ5 IGZvciBjb21taXQgOTRkZmQ3ZWRmZDVjLiAgQmFzaWNhbGx5IHRoZSAKPiA+IGlkZWEgd2FzIHRv IHJlZHVjZSBvdmVyYWxsIGxhdGVuY3kgYnkgbm90IGRvaW5nIGFzIG11Y2ggd29yayBpbiBhbiAK PiA+IGludGVycnVwdCBoYW5kbGVyLgo+ID4gCj4gPiBBbGFuIFN0ZXJuCj4gCj4gc25kX2NvbXBs ZXRlX3VyYiBpcyBkb2luZyBub3RoaW5nIGJ1dCBzdWJtaXR0aW5nIHRoZSBzYW1lIHVyYiBhZ2Fp bi4gSXMgCj4gcmVzdWJtaXR0aW5nIHRoZSB1cmIgcmVhbGx5IGNhdXNpbmcgc28gbXVjaCBsYXRl bmN5IHRoYXQgeW91IGNhbid0IGRvIGl0IAo+IGluIHRoZSBpbnRlcnJ1cHQgaGFuZGxlcj8KCnNu ZF9jb21wbGV0ZV91cmIoKSBkb2VzIG11Y2ggbW9yZSB0aGFuIGp1c3Qgc3VibWl0aW9uIG9mIHRo ZSBzYW1lIHVyYi4KUGVyaGFwcyBpZiB0aGlzIGlzIGEgcmVhbCBwcm9ibGVtLCB0aGUgc291bmQg ZHJpdmVyIHNob3VsZCBoYXZlIG1vcmUKdGhhbiBvbmUgdXJiIHBlbmRpbmc/ICBJcyB0aGVyZSBh IHBvb2wgaGVyZSB0aGF0IGlzIHNvbWVob3cgZ2V0dGluZyB1c2VkCnVwPwoKdGhhbmtzLAoKZ3Jl ZyBrLWgKLS0tClRvIHVuc3Vic2NyaWJlIGZyb20gdGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5lICJ1 bnN1YnNjcmliZSBsaW51eC11c2IiIGluCnRoZSBib2R5IG9mIGEgbWVzc2FnZSB0byBtYWpvcmRv bW9Admdlci5rZXJuZWwub3JnCk1vcmUgbWFqb3Jkb21vIGluZm8gYXQgIGh0dHA6Ly92Z2VyLmtl cm5lbC5vcmcvbWFqb3Jkb21vLWluZm8uaHRtbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,T_DKIMWL_WL_HIGH autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by aws-us-west-2-korg-lkml-1.web.codeaurora.org (Postfix) with ESMTP id 6973EC433EF for ; Tue, 12 Jun 2018 17:53:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1190620891 for ; Tue, 12 Jun 2018 17:53:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="ghBD451V" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1190620891 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754378AbeFLRxF (ORCPT ); Tue, 12 Jun 2018 13:53:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:49114 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754056AbeFLRxE (ORCPT ); Tue, 12 Jun 2018 13:53:04 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 198C220891; Tue, 12 Jun 2018 17:53:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1528825983; bh=aAERSOix1p8OcjwrDDU6VsLhS/tV9+fgqFMBu11b3gM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ghBD451VimzzB+fTV1vTZEZXnxdX9ECopmCIW2HwKcoVaWV+Wla9Vua6jE9skwfef 5oVL3Zv/5E43XN6OHpMILaVi32v72/rL3EawH9G7utxCSac8eL3vosHN1iJ5Y03EmT t1I45w6I9dsk8DO4P2s1dJprzpEEfW2GLcz8G1Ao= Date: Tue, 12 Jun 2018 19:52:42 +0200 From: Greg Kroah-Hartman To: Mikulas Patocka Cc: Alan Stern , Ming Lei , USB list , Kernel development list Subject: Re: [PATCH] usb: don't offload isochronous urb completions to ksoftirq Message-ID: <20180612175242.GA12855@kroah.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 12, 2018 at 01:19:28PM -0400, Mikulas Patocka wrote: > > > 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. Ok, but what happens when you plug your device into a xhci controller? Do we also need to change that? Only touching a specific host controller is not good, you will be playing "whack a mole" for forever. Isoc packets are, by definition, not supposed to be guaranteed at all. So if they are "slow" or dropped or delayed somehow, that's fine. The sound protocol should be fine with it. Now yes, in reality, as you have found out, things can be "tight" on low-powered processors under heavy load. But what you are doing here is a priority inversion. You do not solve such a thing by going around and raising everything else up as well, this is supposed to be a "general purpose" kernel. You can tune a specific machine/device just fine this way, but not by messing with the kernel for the most part. > > > > 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? snd_complete_urb() does much more than just submition of the same urb. Perhaps if this is a real problem, the sound driver should have more than one urb pending? Is there a pool here that is somehow getting used up? thanks, greg k-h