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 grep -l IRQ_WAKE_THREAD | sort | grep -v "\.h" | wc -l 76 ``` So, I'd like to ask: - Why not **all** of the drivers use the threaded interrupts? - What are the cons of the threaded interrupts? Thanks, --- KostaZ
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 <zertsekel@gmail.com> wrote:
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 grep -l IRQ_WAKE_THREAD | sort | grep -v "\.h" | wc -l 76 ```
So, I'd like to ask: - Why not **all** of the drivers use the threaded interrupts? - What are the cons of the threaded interrupts?
Thanks, --- KostaZ
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>> 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 threaded interrupts?
Just a wild assumption: maybe the cost of incurring context switches ? (comparing to tasklets)
I get that threaded IRQ is better than softIrqs because threaded IRQ supports priorities. On the other hand, added context switches surely get system slower. But from the practical point of view - why on relatively new Intel PC there are no threaded irqs at all? ``` $ uname -a Linux kostaz-OptiPlex-7010 3.19.0-26-generic #28-Ubuntu SMP Tue Aug 11 14:16:32 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux ``` --- KostaZ On Thu, Sep 10, 2015 at 11:09 PM, Rami Rosen <roszenrami@gmail.com> wrote:
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 <zertsekel@gmail.com> wrote:
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 grep -l IRQ_WAKE_THREAD | sort | grep -v "\.h" | wc -l 76 ```
So, I'd like to ask: - Why not **all** of the drivers use the threaded interrupts? - What are the cons of the threaded interrupts?
Thanks, --- KostaZ
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
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/touchscreen/ucb1400_ts.c?... How did you came to the conclusion that this kernel does not support threaded IRQs ? could it be that you simply do not use device drivers that use this mechanism ? Regards, Rami Rosen http://ramirose.wix.com/ramirosen On 13 September 2015 at 09:24, Kosta Zertsekel <zertsekel@gmail.com> wrote:
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 threaded interrupts?
Just a wild assumption: maybe the cost of incurring context switches ? (comparing to tasklets)
I get that threaded IRQ is better than softIrqs because threaded IRQ supports priorities. On the other hand, added context switches surely get system slower. But from the practical point of view - why on relatively new Intel PC there are no threaded irqs at all?
``` $ uname -a Linux kostaz-OptiPlex-7010 3.19.0-26-generic #28-Ubuntu SMP Tue Aug 11 14:16:32 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux ```
--- KostaZ
On Thu, Sep 10, 2015 at 11:09 PM, Rami Rosen <roszenrami@gmail.com> wrote:
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 <zertsekel@gmail.com> wrote:
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 grep -l IRQ_WAKE_THREAD | sort | grep -v "\.h" | wc -l 76 ```
So, I'd like to ask: - Why not **all** of the drivers use the threaded interrupts? - What are the cons of the threaded interrupts?
Thanks, --- KostaZ
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On 10 September 2015 at 20:49, Kosta Zertsekel <zertsekel@gmail.com> 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 <roszenrami@gmail.com> wrote: 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/touchscreen/ucb1400_ts.c?...
How did you came to the conclusion that this kernel does not support threaded IRQs ? could it be that you simply do not use device drivers that use this mechanism ?
In the given touch screen driver request_threaded_irq() provides NULL for the thread function pointer. Hence, the non-threaded IRQ mechanism is actually being used. This is why I grepped for IRQ_WAKE_THREAD and not for request_threaded_irq. So, the questions remains. Why only ~76 drivers use the threaded IRQ mechanism? What are the cons of the threaded IRQ mechanism? Thanks, --- KostaZ
On Tue, Sep 15, 2015 at 09:02:24PM +0300, Kosta Zertsekel wrote:
On 10 September 2015 at 20:49, Kosta Zertsekel <zertsekel@gmail.com> 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 <roszenrami@gmail.com> wrote: 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/touchscreen/ucb1400_ts.c?... =3.18
How did you came to the conclusion that this kernel does not support threaded IRQs ? could it be that you simply do not use device drivers that use this mechanism ?
In the given touch screen driver request_threaded_irq() provides NULL for the thread function pointer. Hence, the non-threaded IRQ mechanism is actually being used. This is why I grepped for IRQ_WAKE_THREAD and not for request_threaded_irq.
So, the questions remains. Why only ~76 drivers use the threaded IRQ mechanism?
Because people have not converted older code to the newer mechanism.
What are the cons of the threaded IRQ mechanism?
Slower throughput and added complexity.
participants (3)
-
Greg KH -
Kosta Zertsekel -
Rami Rosen