From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757780AbbJIKhc (ORCPT ); Fri, 9 Oct 2015 06:37:32 -0400 Received: from www.linutronix.de ([62.245.132.108]:36815 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757752AbbJIKh0 (ORCPT ); Fri, 9 Oct 2015 06:37:26 -0400 Date: Fri, 9 Oct 2015 12:36:33 +0200 (CEST) From: Thomas Gleixner To: Felipe Balbi cc: hpa@zytor.com, okuno.kohji@jp.panasonic.com, bigeasy@linutronix.de, linux-kernel@vger.kernel.org, msmucr@gmail.com, nathan.sullivan@ni.com, mingo@kernel.org, linux-tip-commits@vger.kernel.org Subject: Re: [tip:irq/core] genirq: Handle force threading of irqs with primary and thread handler In-Reply-To: <87twq3257l.fsf@saruman.tx.rr.com> Message-ID: References: <87twq3257l.fsf@saruman.tx.rr.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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). > > 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. It's not only an issue for SDHCI. It's a general problem with other drivers as well. > 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. > 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. I'm surprised of the size of the impact as well. I wouldn't have expected that another kernel thread context switch makes such a difference. Thanks, tglx