Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752403AbcCGHeH (ORCPT ); Mon, 7 Mar 2016 02:34:07 -0500 Received: from mga01.intel.com ([192.55.52.88]:16069 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752025AbcCGHeD (ORCPT ); Mon, 7 Mar 2016 02:34:03 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,550,1449561600"; d="asc'?scan'208";a="928327690" From: Felipe Balbi To: Felipe Ferreri Tonello , linux-usb@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Michal Nazarewicz , Clemens Ladisch Subject: Re: [PATCH 2/5] usb: gadget: f_midi: added spinlock on transmit function In-Reply-To: References: <1456947640-20673-1-git-send-email-eu@felipetonello.com> <1456947640-20673-3-git-send-email-eu@felipetonello.com> <87twkm676d.fsf@ti.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/25.0.90.3 (x86_64-pc-linux-gnu) Date: Mon, 07 Mar 2016 09:32:29 +0200 Message-ID: <87h9gikak2.fsf@intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2750 Lines: 82 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, (please break your lines at 80-characters, have a look at Documentation/email-clients.txt if needed) Felipe Ferreri Tonello writes: > [ text/plain ] > Hi Balbi,=20 > > On March 4, 2016 7:20:10 AM GMT+00:00, Felipe Balbi wr= ote: >> >>Hi, >> >>"Felipe F. Tonello" writes: >>> [ text/plain ] >>> Since f_midi_transmit is called by both ALSA and USB frameworks, it >>can >>> potentially cause a race condition between both calls. This is bad >>because the >>> way f_midi_transmit is implemented can't handle concurrent calls. >>This is due >>> to the fact that the usb request fifo looks for the next element and >>only if >>> it has data to process it enqueues the request, otherwise re-uses it. >>If both >>> (ALSA and USB) frameworks calls this function at the same time, the >>> kfifo_seek() will return the same usb_request, which will cause a >>race >>> condition. >>> >>> To solve this problem a syncronization mechanism is necessary. In >>this case it >>> is used a spinlock since f_midi_transmit is also called by >>usb_request->complete >>> callback in interrupt context. >>> >>> On benchmarks realized by me, spinlocks were more efficient then >>scheduling >>> the f_midi_transmit tasklet in process context and using a mutex to >>> synchronize. Also it performs better then previous implementation >>that >>> allocated a usb_request for every new transmit made. >> >>behaves better in what way ? Also, previous implementation would not >>suffer from this concurrency problem, right ? > > The spin lock is faster than allocating usb requests all the time, > even if the udc uses da for it. did you measure ? Is the extra speed really necessary ? How did you benchmark this ? =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJW3S6NAAoJEIaOsuA1yqREq/IP/RmScxw/qq2JDp/iLfqP7q7s aLYw43tPW2CYgyUVUhUqn8+q3xxSQJucKGH+q+jJRqpt5CQKSCM387KazBSFLd4B fknTtGhHLGal3c9n8jss47N6WCgybF7GaFEGrFcj3pdHH8B9C58hwZwKCObpHxLd gM3ufaNhTRicLklQ85rb4w9sR77Z1wulrdTlKVfnNBcfNhP2rtw9X+cH2dDboJdg aMUbbBX0uQTXZpV9imi8QyfiMdN5xGA3y6Q4F+0Q4kOz6t00ui1iJ/UCYhUBOIKu MD/7fNyyr1vfc/3dVYM8/4lurv6dfX3uzG+W/nnohgJxbDdjqj5dPHtE0srOnc5K TsXE9xbU1gFRt26NdoC0Zz3/lhOwh+Vsc16pS2w0Ap+Xx3m3aHkofu4+QOg4x7p1 7b2QAX8Uy4oKgCJ1nheZN60qbrk1eH8bB8d1TeZQU3HMcgnzibcj/KWOh5mYtcCm Cbr2hDOzo8BNXQjioc2OouIlnQ0JcsC/WVTQbGrG0QKvaA8KMW5StFQ0V5JnZv3D 4TE6ydO8Wt2N+qn+sgGu6jHdRdsOfb8QcOnhM/DYSU0bYvy0e3Hp7N+6RgrdRAXc NyA/CblCiKBShAzBP4zPEETj+FlrrneRhWoKSP1uO4ajWYhM8RnnT/TGyBrgyGUt Qr0xqkHLwbxiib24UCf0 =S3iP -----END PGP SIGNATURE----- --=-=-=--