When a threaded irq handler is installed the irq thread is initially created
on normal scheduling priority. Only after the the irq thread is woken up it
sets its priority to RT_FIFO MAX_USER_RT_PRIO/2.

This means that interrupts that occur directly after the irq handler is
installed will be handled on a normal scheduling priority instead of the
realtime priority that you would expect. Fixed this by setting the RT
priority on creation of the irq_thread.

Signed-off-by: Ivo Sieben <meltedpiano...@gmail.com>
---

RFC:
Whas there a specific reason for the irq_thread to be created on normal
scheduling and only set to RT priority when woken up?
This patch solves an issue for me where a device driver is expected to handle an
interrupt immediatly after irq handlers are installed and interrupts enabled.

(If this does make sense: I guess the sched_setscheduler() call in the 
irq_thread
function can be removed?)

 kernel/irq/manage.c |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index fa17855..0ffe37b 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -950,6 +950,9 @@ __setup_irq(unsigned int irq, struct irq_desc *desc, struct 
irqaction *new)
         */
        if (new->thread_fn && !nested) {
                struct task_struct *t;
+               static const struct sched_param param = {
+                       .sched_priority = MAX_USER_RT_PRIO/2,
+               };
 
                t = kthread_create(irq_thread, new, "irq/%d-%s", irq,
                                   new->name);
@@ -957,6 +960,9 @@ __setup_irq(unsigned int irq, struct irq_desc *desc, struct 
irqaction *new)
                        ret = PTR_ERR(t);
                        goto out_mput;
                }
+
+               sched_setscheduler(t, SCHED_FIFO, &param);
+
                /*
                 * We keep the reference to the task struct even if
                 * the thread dies to avoid that the interrupt code
-- 
1.7.9.5


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to