From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752747AbbJFTAH (ORCPT ); Tue, 6 Oct 2015 15:00:07 -0400 Received: from bear.ext.ti.com ([192.94.94.41]:39340 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752365AbbJFTAF (ORCPT ); Tue, 6 Oct 2015 15:00:05 -0400 From: Felipe Balbi To: , , , , , , , , CC: , , , , , , , Subject: Re: [tip:irq/core] genirq: Handle force threading of irqs with primary and thread handler In-Reply-To: References: User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 6 Oct 2015 13:59:42 -0500 Message-ID: <87twq3257l.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, tip-bot for Thomas Gleixner writes: > Commit-ID: 2a1d3ab8986d1b2f598ffc42351d94166fa0f022 > Gitweb: http://git.kernel.org/tip/2a1d3ab8986d1b2f598ffc42351d94166fa= 0f022 > Author: Thomas Gleixner > AuthorDate: Mon, 21 Sep 2015 11:01:10 +0200 > Committer: Thomas Gleixner > CommitDate: Tue, 22 Sep 2015 12:39:57 +0200 > > genirq: Handle force threading of irqs with primary and thread handler > > Force threading of interrupts does not really deal with interrupts > which are requested with a primary and a threaded handler. The current > policy is to leave them alone and let the primary handler run in > interrupt context, but we set the ONESHOT flag for those interrupts as > well. > > Kohji Okuno debugged a problem with the SDHCI driver where the > interrupt thread waits for a hardware interrupt to trigger, which can't > work well because the hardware interrupt is masked due to the ONESHOT > flag being set. He proposed to set the ONESHOT flag only if the > interrupt does not provide a thread handler. > > Though that does not work either because these interrupts can be > shared. So the other interrupt would rightfully get the ONESHOT flag > set and therefor the same situation would happen again. > > To deal with this proper, we need to force thread the primary handler > of such interrupts as well. That means that the primary interrupt > handler is treated as any other primary interrupt handler which is not > marked IRQF_NO_THREAD. The threaded handler becomes a separate thread > so the SDHCI flow logic can be handled gracefully. > > The same issue was reported against 4.1-rt. > > Reported-and-tested-by: Kohji Okuno > Reported-By: Michal Smucr > Reported-and-tested-by: Nathan Sullivan > Signed-off-by: Thomas Gleixner > Cc: Sebastian Andrzej Siewior > Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1509211058080.5606@nanos > Signed-off-by: Thomas Gleixner this commit causes a performance regression for the USB driver on several platforms (anybody using drivers/usb/dwc3, basically). Here's the USB throughput with linux-next in 3 different scenarios: 1) Linux next without threadirqs cmdline test 0: sent 256.00 MB read 33.02 MB/s write 30.01 MB/s 2) Linux next with threadirqs on cmdline test 0: sent 256.00 MB read 30.70 MB/s write 27.89 MB/s 3) Linux next with threadirqs on cmdline + revert of $subject test 0: sent 256.00 MB read 32.93 MB/s write 29.85 MB/s 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. 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. It's a bit surprising, to me at least, that simply running everything as a thread would have such a measurable impact, but it does. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWFBofAAoJEIaOsuA1yqREaVAP/26mf9tkKrlED7TFZtbTdngn v1Xo0aQhJgs9OtZJxYx0p/f8VzxBP5E79bv2VQUd87tToFZ0EZ9XaixVYBxPxVE+ LuIeoyJ2JwNc+Ry3X9kQa/7aQhNdD5kIlUZa2sPFaIsx1gqPAj0oe/8mUPIYtlVq K/Sf7ZbYoa9ufyR/jXzkrbyWBb/YY7ClFlKARahxN+0ujmvmCss17rSV6g6zd6nK 0rc5z4VobSCuTT/7fxZGXnq/yWX0ki8y5xfh3mK3DSI5m+fUQKHwnbvEsfWnQZHa OVp0gdHeZLrvJK4KjXBPn/viGWJKaBx+BiGu9aOXqnw3a9XemeMEjjTV31msG1kY uKuxBX/gSDULZUtrV0ylXVnvBcncjOYSj7qJN9WYMqCiV/uYia5+dblgxihN1LAo oEbag//PxvR/bm1L7DsAtayalHGkklGlNiyic1lOnv7zvWCx0Y6AFnB9nU96XYTK F0AYmjKIUEyXLM90bbMa4GS2Qn6adiRfsBU9cy65pVBtdrMyEPLDISZXPSVJNk19 hPvLSDeP8KQ9PVjljVZHY/8C5MF3z551s8uyLV7h0Ze3qPzCNm0iYgVuqAPKKdpO x+eJDOOGyL9ixP9lfOa2Q7oDUvN/niJhkjYiGFYDZFOwYNZxomRyzLlKsjQv70gI QuOaN4apQB3W6dxRgEGQ =JZr+ -----END PGP SIGNATURE----- --=-=-=--