linux-kernel - Re: [tip:irq/core] genirq: Handle force threading of irqs with primary and thread handler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 9 Oct 2015 12:36:33 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Felipe Balbi <balbi@...com>
cc:	hpa@...or.com, okuno.kohji@...panasonic.com, bigeasy@...utronix.de,
	linux-kernel@...r.kernel.org, msmucr@...il.com,
	nathan.sullivan@...com, mingo@...nel.org,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:irq/core] genirq: Handle force threading of irqs with
 primary and thread handler

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/