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] [day] [month] [year] [list]

Date:	Fri, 9 Oct 2015 09:01:28 -0500
From:	Felipe Balbi <balbi@...com>
To:	Thomas Gleixner <tglx@...utronix.de>
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


Hi,

Thomas Gleixner <tglx@...utronix.de> 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).
>> 
>> 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.

all right. I'll patch that up. Thanks

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (819 bytes)