Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1243401

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

From Felipe Balbi <balbi@ti.com>
Newsgroups linux.kernel
Subject Re: [tip:irq/core] genirq: Handle force threading of irqs with primary and thread handler
Date 2015-10-09 16:10 +0200
Message-ID <qhGwW-4li-19@gated-at.bofh.it> (permalink)
References <qb5gK-297-13@gated-at.bofh.it> <qbtj4-2Wc-17@gated-at.bofh.it> <qgFMB-6Ge-5@gated-at.bofh.it> <qhDfI-7Wk-13@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

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

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

Re: [tip:irq/core] genirq:  Handle force threading of irqs with primary and thread handler Felipe Balbi <balbi@ti.com> - 2015-10-06 21:10 +0200
  Re: [tip:irq/core] genirq: Handle force threading of irqs with  primary and thread handler Thomas Gleixner <tglx@linutronix.de> - 2015-10-09 12:40 +0200
    Re: [tip:irq/core] genirq: Handle force threading of irqs with primary and thread handler Felipe Balbi <balbi@ti.com> - 2015-10-09 16:10 +0200

csiph-web