lkml.org 
[lkml]   [2015]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [tip:irq/core] genirq: Handle force threading of irqs with primary and thread handler
Date

Hi,

Thomas Gleixner <tglx@linutronix.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
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2015-10-09 16:21    [W:1.065 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site