On Tue, Sep 15, 2015 at 09:02:24PM +0300, Kosta Zertsekel wrote:
> >> On 10 September 2015 at 20:49, Kosta Zertsekel
> >> Also, I see that in 4.2 there are only ~76 drivers that use threaded
> >> interrupt:
> >> ```
> >> $ git grep -l IRQ_WAKE_THREAD | sort | grep -v "\.h" | wc -l
> >> 76
> >> ```
>> On 10 September 2015 at 20:49, Kosta Zertsekel
>> Also, I see that in 4.2 there are only ~76 drivers that use threaded
>> interrupt:
>> ```
>> $ git grep -l IRQ_WAKE_THREAD | sort | grep -v "\.h" | wc -l
>> 76
>> ```
> On Sun, Sep 13, 2015 at 2:16 PM, Rami Rosen wrote:
> This kernel and older
Kosta,
This kernel and older ones include device drivers which use threaded IRQs
(call request_threaded_irq(), etc).
For example, many of the driver under drivers/input/touchscreen are
using threaded IRQs:
Following link is from kernel 3.18:
http://lxr.free-electrons.com/source/drivers/input/touc
>> I think I get the pro of using threaded interrupts - to decrease the
maximum
>> interrupt latency on RT workloads and/or RT machines (servers, embedded,
>> etc.).
>> So, I'd like to ask:
>>- Why not **all** of the drivers use the threaded interrupts?
>>- What are the cons of the thread
Kosta,
Just a wild assumption: maybe the cost of incurring context switches ?
(comparing to tasklets)
Best Regards,
Rami Rosen
http://ramirose.wix.com/ramirosen
On 10 September 2015 at 20:49, Kosta Zertsekel wrote:
> Hi guys,
>
> I hope I'm on right mailing list. :-)
> I think I get the pro o
Hi guys,
I hope I'm on right mailing list. :-)
I think I get the pro of using threaded interrupts - to decrease the maximum
interrupt latency on RT workloads and/or RT machines (servers, embedded,
etc.).
Also, I see that in 4.2 there are only ~76 drivers that use threaded
interrupt:
```
$ git gre
