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

[Felipe Balbi]

Hi,

Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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

Attachment: signature.asc
Description: PGP signature