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: [6/6] usb: musb: Decrease URB starting latency in musb_advance_schedule() From: Alan Stern Message-Id: Date: Tue, 30 Apr 2019 13:29:35 -0400 (EDT) To: Bin Liu Cc: "Matwey V. Kornilov" , gregkh@linuxfoundation.org, matwey.kornilov@gmail.com, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org List-ID: T24gVHVlLCAzMCBBcHIgMjAxOSwgQmluIExpdSB3cm90ZToKCj4gSGkgR3JlZyBhbmQgYWxsIGRl dnMsCj4gCj4gT24gV2VkLCBBcHIgMDMsIDIwMTkgYXQgMDk6NTM6MTBQTSArMDMwMCwgTWF0d2V5 IFYuIEtvcm5pbG92IHdyb3RlOgo+ID4gUHJldmlvdXNseSwgdGhlIGFsZ29yaXRobSB3YXMgdGhl IGZvbGxvd2luZzoKPiA+IAo+ID4gIDEuIGdpdmViYWNrIGN1cnJlbnQgVVJCCj4gPiAgMi4gaWYg Y3VycmVudCBxaCBpcyBub3QgZW1wdHkKPiA+ICAgICB0aGVuIHN0YXJ0IG5leHQgVVJCCj4gPiAg My4gaWYgY3VycmVudCBxaCBpcyBlbXB0eQo+ID4gICAgIHRoZW4gZGlzcG9zZSB0aGUgcWgsIGZp bmQgbmV4dCBxaCBpZiBhbnksIGFuZCBzdGFydCBVUkIuCj4gPiAKPiA+IEl0IG1heSB0YWtlIGEg d2hpbGUgdG8gcnVuIHVyYi0+Y2FsbGJhY2sgaW5zaWRlIFVSQiBnaXZlYmFjayB3aGljaCBpcwo+ ID4gcnVuIHN5bmNocm9ub3VzbHkgaW4gbXVzYi4gSW4gb3JkZXIgdG8gaW1wcm92ZSB0aGUgbGF0 ZW5jeSB3ZSByZWFycmFuZ2UKPiA+IHRoZSBmdW5jdGlvbiBiZWhhdmlvdXIgZm9yIHRoZSBjYXNl IHdoZW4gcWggaXMgbm90IGVtcHR5OiBuZXh0IFVSQiBpcwo+ID4gc3RhcnRlZCBiZWZvcmUgVVJC IGdpdmViYWNrLiBXaGVuIHFoIGlzIGVtcHR5IHRoZW4gdGhlIGJlaGF2aW91ciBpcwo+ID4gaW50 ZW50aW9uYWxseSBrZXB0IGluIG9yZGVyIG5vdCB0byBicmVhayBleGlzdGluZyBpbnRlciBxaCBz Y2hlZHVsaW5nOgo+ID4gVVJCIGdpdmViYWNrIGNvdWxkIHBvdGVudGlvbmFsbHkgZW5xdWV1ZSBv dGhlciBVUkIgdG8gdGhlIGVtcHR5IHFoCj4gPiBwcmV2ZW50aW5nIGl0IGZyb20gYmVpbmcgZGlz cG9zZWQuCj4gCj4gVGhpcyBwYXRjaCBjaGFuZ2VzIHRoZSBzZXF1ZW5jZSBvZiB1cmIgZ2l2ZWJh Y2sgaW4gbXVzYi4KPiAKPiAJYmVmb3JlCQkJCWFmdGVyCj4gCS0tLS0tLQkJCQktLS0tLQo+IDEu IGdpdmViYWNrIGN1cnJlbnQgdXJiCQkJMS4gc3RhcnQgbmV4dCB1cmIgaWYgcWggIT0gZW1wdHkK PiAyLiBzdGFydCBuZXh0IHVyYiBpZiBxaCAhPSBlbXB0eQkyLiBnaXZlYmFjayBjdXJyZW50IHVy Ygo+IAo+IEkgc2VlIHRoZXJlIGlzIGEgcG90ZW50aWFsIHRoYXQgdGhlIHVyYiBnaXZlYmFjayBj b3VsZCBiZSBvdXQgb2Ygb3JkZXIsCj4gZm9yIGV4YW1wbGUsIGlmIHVyYiBnaXZlYmFjayBpbiBC SCBhbmQgdGhlIG5leHQgdXJiIGZpbmlzaGVzIGJlZm9yZSBCSAo+IHJ1bnMuCj4gCj4gSWYgdGhp cyBwb3RlbnRpYWwgaXMgcG9zc2libGUsIGlzIGl0IGEgcHJvYmxlbSBmb3IgYW55IGNsYXNzIGRy aXZlcj8KCkkgZG9uJ3Qga25vdyBvZiBhbnkgc3BlY2lmaWMgZXhhbXBsZXMgd2hlcmUgdGhpcyB3 b3VsZCBiZSBhIHByb2JsZW0uICAKQnV0IGl0IGRlZmluaXRlbHkgZ29lcyBhZ2FpbnN0IHRoZSBn dWFyYW50ZWUgdGhhdCBleGNlcHQgZm9yIHVubGlua3MsIApVUkJzIGZvciBlYWNoIGVuZHBvaW50 IGFyZSBhbHdheXMgZ2l2ZW4gYmFjayBpbiBvcmRlci4KClRoZXJlJ3MgYWxzbyBhIGd1YXJhbnRl ZSB0aGF0IHdoZW4gYW4gVVJCIGhhcyBhbiBlcnJvciBzdGF0dXMsIGl0CmNhdXNlcyB0aGUgZW5k cG9pbnQgcXVldWUgdG8gc3RvcC4gIFRoaXMgaXMgbmVjZXNzYXJ5IHNvIHRoYXQgdGhlIGNsYXNz CmRyaXZlciBjYW4gY2FuY2VsIGFueSBvdXRzdGFuZGluZyBVUkJzIGJlZm9yZSB0aGV5IHJ1biBh bmQgY2F1c2UgZXZlbgptb3JlIHRyb3VibGUuICBZb3VyIGJyaWVmIG91dGxpbmUgYWJvdmUgZG9l c24ndCBtZW50aW9uIHRoaXMuCgpPbiB0aGUgb3RoZXIgaGFuZCwgaXQgc2hvdWxkbid0IGJlIGhh cmQgdG8gbWFpbnRhaW4gdGhlIG9yZGVyIGV2ZW4KaGVyZS4gIEZvciBleGFtcGxlLCB5b3UgY291 bGQgaGF2ZSBhIEZJRk8gbGlzdCBvZiBVUkJzIHdhaXRpbmcgdG8gYmUKZ2l2ZW4gYmFjaywgYW5k IHRoZSBCSCBjb3VsZCBhbHdheXMgZ2l2ZSBiYWNrIHRoZSBVUkIgYXQgdGhlIGZyb250IG9mCnRo ZSBsaXN0LgoKQWxhbiBTdGVybgo= 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.9 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E76AFC43219 for ; Tue, 30 Apr 2019 17:29:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C024521670 for ; Tue, 30 Apr 2019 17:29:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726073AbfD3R3g (ORCPT ); Tue, 30 Apr 2019 13:29:36 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:36014 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1725930AbfD3R3g (ORCPT ); Tue, 30 Apr 2019 13:29:36 -0400 Received: (qmail 5374 invoked by uid 2102); 30 Apr 2019 13:29:35 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 30 Apr 2019 13:29:35 -0400 Date: Tue, 30 Apr 2019 13:29:35 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Bin Liu cc: "Matwey V. Kornilov" , , , , Subject: Re: [PATCH 6/6] usb: musb: Decrease URB starting latency in musb_advance_schedule() In-Reply-To: <20190430153118.GI20993@uda0271908> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Sender: linux-usb-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org Message-ID: <20190430172935.2qjW2yinKlhX5jObbXAY9Puv8KuGJtaT_hKorUdYOGk@z> On Tue, 30 Apr 2019, Bin Liu wrote: > Hi Greg and all devs, > > On Wed, Apr 03, 2019 at 09:53:10PM +0300, Matwey V. Kornilov wrote: > > Previously, the algorithm was the following: > > > > 1. giveback current URB > > 2. if current qh is not empty > > then start next URB > > 3. if current qh is empty > > then dispose the qh, find next qh if any, and start URB. > > > > It may take a while to run urb->callback inside URB giveback which is > > run synchronously in musb. In order to improve the latency we rearrange > > the function behaviour for the case when qh is not empty: next URB is > > started before URB giveback. When qh is empty then the behaviour is > > intentionally kept in order not to break existing inter qh scheduling: > > URB giveback could potentionally enqueue other URB to the empty qh > > preventing it from being disposed. > > This patch changes the sequence of urb giveback in musb. > > before after > ------ ----- > 1. giveback current urb 1. start next urb if qh != empty > 2. start next urb if qh != empty 2. giveback current urb > > I see there is a potential that the urb giveback could be out of order, > for example, if urb giveback in BH and the next urb finishes before BH > runs. > > If this potential is possible, is it a problem for any class driver? I don't know of any specific examples where this would be a problem. But it definitely goes against the guarantee that except for unlinks, URBs for each endpoint are always given back in order. There's also a guarantee that when an URB has an error status, it causes the endpoint queue to stop. This is necessary so that the class driver can cancel any outstanding URBs before they run and cause even more trouble. Your brief outline above doesn't mention this. On the other hand, it shouldn't be hard to maintain the order even here. For example, you could have a FIFO list of URBs waiting to be given back, and the BH could always give back the URB at the front of the list. Alan Stern