Hi Thomas, tip-bot for Thomas Gleixner <tipbot@xxxxxxxxx> writes: > Commit-ID: 2a1d3ab8986d1b2f598ffc42351d94166fa0f022 > Gitweb: http://git.kernel.org/tip/2a1d3ab8986d1b2f598ffc42351d94166fa0f022 > Author: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > AuthorDate: Mon, 21 Sep 2015 11:01:10 +0200 > Committer: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > 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 <okuno.kohji@xxxxxxxxxxxxxxxx> > Reported-By: Michal Smucr <msmucr@xxxxxxxxx> > Reported-and-tested-by: Nathan Sullivan <nathan.sullivan@xxxxxx> > Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > Cc: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> > Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1509211058080.5606@nanos > Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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. -- balbi
Attachment:
signature.asc
Description: PGP signature
|