From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754923AbbJIOBu (ORCPT ); Fri, 9 Oct 2015 10:01:50 -0400 Received: from arroyo.ext.ti.com ([192.94.94.40]:47165 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754683AbbJIOBt (ORCPT ); Fri, 9 Oct 2015 10:01:49 -0400 From: Felipe Balbi To: Thomas Gleixner CC: , , , , , , , Subject: Re: [tip:irq/core] genirq: Handle force threading of irqs with primary and thread handler In-Reply-To: References: <87twq3257l.fsf@saruman.tx.rr.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Fri, 9 Oct 2015 09:01:28 -0500 Message-ID: <8737xkw37r.fsf@saruman.tx.rr.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-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Thomas Gleixner writes: > On Tue, 6 Oct 2015, Felipe Balbi wrote: >> this commit causes a performance regression for the USB driver on >> several platforms (anybody using drivers/usb/dwc3, basically). >>=20 >> Here's the USB throughput with linux-next in 3 different scenarios: >>=20 >> 1) Linux next without threadirqs cmdline >>=20 >> test 0: sent 256.00 MB read 33.02 MB/s write 30.01 MB/s >>=20 >> 2) Linux next with threadirqs on cmdline >>=20 >> test 0: sent 256.00 MB read 30.70 MB/s write 27.89 MB/s >>=20 >> 3) Linux next with threadirqs on cmdline + revert of $subject >>=20 >> test 0: sent 256.00 MB read 32.93 MB/s write 29.85 MB/s >>=20 >>=20 >> Considering this is trying to solve an issue found on the SDHCI driver, >> shouldn't that be fixed instead ? Another option would be, of course, to >> add IRQF_NO_THREAD to dwc3, but I'd like to avoid that if possible. > > It's not only an issue for SDHCI. It's a general problem with other > drivers as well. >=20=20 >> The way we try to use dwc3 is rather simple, actually. We use the >> primary handle *only* to detect is $this device generated the IRQ and if >> did we wake up the thread. We also don't make use of ONESHOT because we >> mask $this device IRQs in the primary handler and only unmask after the >> thread runs. > > So in your case IRQF_NO_THREAD is really the solution. It will keep > your primary handler handled in the hard interrupt context. That will > work on RT as well. all right. I'll patch that up. Thanks =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWF8i6AAoJEIaOsuA1yqREujAP+gKMrFMoRxZjQaCo+KxXCScS QnsD24Ce7N/vyWax8UJ1qKJAlo8SRibVxb995DhS4UT9u4iK7vcg6DOhFTGdycUt jT56Eu7r2B96B8x18zdEivfYfxQg1UU5+6U905XQYshkIVBTtqchar5eChUSVNO1 GK0DlgKpcaPowKVBEUrkjOBcIUIMyddNlMPaHvC+4y+8wWpbouz+edaWYJ9dEOgM z6rjDx9CxAbPmSVQvma2RCPLOaLg/1GoaNOdgmQDMbJBvSrh3GM1VEz87JXN3E2l Y0se3ergMC7G7TD6JtRFx0Z0wC6X8X/GbdhaQFGzdVfgcJ8QOOFidC2gvY8Stp6b Z4icfhGpufmpLJjN1+VT4UOuFXwVIhfGx/t4h0bzVM1el3S7uprfMeORPHPurguM 7x/c+V04bZHi9/X7/WzhgmwS2k2rW205nm6vNPbH21JWmea02wAK664CLAKk3zd9 Zc3sWQyGj+THpC/p+rtBh2LmhaKE8J1dEg8OaLJpcyaS7aq7MOtjn0fA3GvBVMLa sMAuLphEPhus2y4ypaRs8EaX70W8m2di6gmY4/DPEvCqukPYhv8rS8OtbqXr9B/h 442Z0LiBkZL+sUS2TRoHpa/TMj7k4hRfE5p5xKoyYJYox40WWaNYywLGdDWgFjp/ FxxBy8AA3j8U0oEx/xfc =0dxj -----END PGP SIGNATURE----- --=-=-=--