Threaded interrupt handlers

Not all interrupts are triggers for the real-time tasks but all interrupts steal cycles from the real-time task. Threaded interrupt handlers allow a priority to be associated with the interrupt and for it to be scheduled at an appropriate time as shown in the following diagram:

Threaded interrupt handlers

If the interrupt handler code is run as a kernel thread there is no reason why it cannot be preempted by a user space thread of higher priority, and so the interrupt handler does not contribute towards scheduling latency of the user space thread. Threaded interrupt handlers have been a feature of mainline Linux since 2.6.30. You can request that an individual interrupt handler is threaded by registering it with request_threaded_irq() in place of the normal request_irq(). You can make threaded IRQs the default by configuring the kernel with CONFIG_IRQ_FORCED_THREADING=y which makes all handlers into threads unless they have explicitly prevented this by setting the IRQF_NO_THREAD flag. When you apply the PREEMPT_RT patches, interrupts are, by default, configured as threads in this way. Here is an example of what you might see:

# ps -Leo pid,tid,class,rtprio,stat,comm,wchan | grep FF
PID     TID     CLS     RTPRIO  STAT    COMMAND          WCHAN
3       3       FF      1       S      ksoftirqd/0      smpboot_th
7       7       FF      99      S      posixcputmr/0    posix_cpu_
19      19      FF      50      S      irq/28-edma      irq_thread
20      20      FF      50      S      irq/30-edma_err  irq_thread
42      42      FF      50      S      irq/91-rtc0      irq_thread
43      43      FF      50      S      irq/92-rtc0      irq_thread
44      44      FF      50      S      irq/80-mmc0      irq_thread
45      45      FF      50      S      irq/150-mmc0     irq_thread
47      47      FF      50      S      irq/44-mmc1      irq_thread
52      52      FF      50      S      irq/86-44e0b000  irq_thread
59      59      FF      50      S      irq/52-tilcdc    irq_thread
65      65      FF      50      S      irq/56-4a100000  irq_thread
66      66      FF      50      S      irq/57-4a100000  irq_thread
67      67      FF      50      S      irq/58-4a100000  irq_thread
68      68      FF      50      S      irq/59-4a100000  irq_thread
76      76      FF      50      S      irq/88-OMAP UAR  irq_thread

In this case, a BeagleBone running linux-yocto-rt, only the gp_timer interrupt was not threaded. It is normal that the timer interrupt handler be run in-line.

Note

Note that the interrupt threads have all been given the default policy SCHED_FIFO and a priority of 50. It doesn't make sense to leave them with the defaults, however; now is your chance to assign priorities according to the importance of the interrupts compared to real-time user space threads.

Here is a suggested order of descending thread priorities:

  • The POSIX timers thread, posixcputmr, should always have the highest priority.
  • Hardware interrupts associated with the highest priority real-time thread.
  • The highest priority real-time thread.
  • Hardware interrupts for the progressively lower priority real-time threads followed by the thread itself.
  • Hardware interrupts for non-real-time interfaces.
  • The soft IRQ daemon, ksoftirqd, which on RT kernels is responsible for running delayed interrupt routines and, prior to Linux 3.6, was responsible for running the network stack, the block I/O layer, and other things. You may need to experiment with different priority levels to get a balance.

You can change the priorities using the chrt command as part of the boot script, using a command like this:

# chrt -f -p 90 `pgrep irq/28-edma`

The pgrep command is part of the procps package.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.142.199.184