Concept of ISR in Linux

In this article, i am going to discuss about Interrupt handling mechanism of Linux kernel.

So the story starts from When an interrupts occurs, the processor looks if interrupts are masked. If they are, nothing happens until they are unmasked. When interrupts become unmasked, if there are any pending interrupts, the processor picks one. Then the processor executes the interrupt by branching to a particular address in memory. The code at that address is called the interrupt handler. When the processor branches there, it masks interrupts (so the interrupt handler has exclusive control) and saves the contents of some registers in stack. When the handler finishes executing, it executes a special return-from-interrupt instruction that restores the saved registers and unmasks interrupts.

The problem over here is :

The Corresponding interrupt is disabled during the execution of a interrupt handler, the interrupt handler expected to be finish fast But, what if you have to do a lot of data processing, memory allocation in a interrupt handler.

After kernel release of 2.6 this problem is resolved by designing and developing proper interrupt handling mechanism. Which splits he interrupt handling in to two parts. 

  1. Top-Half: The top half is the real interrupt handler: It just tells the kernel to run the bottom half, and exits. The kernel guarantees that the top half is never re-entered: if another interrupt arrives, it is queued until the top half is finished. Because the top half disables interrupts, it has to be very fast.
  2. Bottom-Half: The bottom half is run after the interrupts are processed(Top half is executed).The interrupts are not disabled while the bottom half is run, so it can do slower actions.

NOTE: Its totally device driver developers choice to split interrupt processing or not. If the ISR is going to very short and can be managed then there is no need of  bottom-half. Similarly, if the disabled interrupt for a long time is OK for use case, then healthy top half is also possible. So, it is a totally design decision.

Linux provides three mechanism to implement bottom half.

1. softIrq : 

It is a vector of 10 different entries (in kernel 3.16) supporting variety of bottom half processing also called software interrupt. All entries are shown by the image below.



  • Softirqs are statically allocated at compile-time. So there are fixed number of softirq and they run in priority order.
  • Softirqs have strong CPU affinity, so they are reserved for most of time critical and important bottom half processing on the system.
  • softirq is guaranteed to run on the CPU it was scheduled on in SMP systems.
  • It Runs in interrupt context, so Interrupt context cannot perform certain actions that can result in the kernel putting the current context to sleep, such as downing a semaphore, copying to or from user-space memory or non-atomically allocating memory
  • it can’t preempted and can’t scheduled
  • Atomic execution
  • it can run simultaneously on one or more processor, even two of the same type of softirq can run concurrently

Softirqs are most often raised from within interrupt handlers. First the interrupt handler(top half) performs the basic hardware-related work, raises the softirq, and then exits. After the kernel is done processing interrupts, it checks wither any of the softirqs have been raised or not. Code flow in Linux kernel for interrupt handling is explained below.


 | do_IRQ()  (top half which masks all interrupts and invoke softirq)

   | irq_exit() (Release all masked interrupts)

     | invoke_softirq() (Kernel checks for the any pending invoked irq)

       | do_softirq() (Execution of softirq (bottom half) with )

2. Tasklet

Tasklets are build on top of softirq. The central idea of tasklet is to provide rich bottom half mechanisum. Only below points diffres from softirq.

  • Tasklets have a weaker CPU affinity than softirqs
  • Unlike softirqs, tasklets are dynamically allocated.
  • A tasklet can run on only one CPU at a time.
  • Runs in interrupt contex, Interrupt context cannot perform certain actions that can result in the kernel putting the current context to sleep, such as downing a semaphore, copying to or from user-space memory or non-atomically allocating memory
  • Atomic execution
  • Two different tasklets can run concurrently on different processors, but two of the same type of tasklet cannot run simultaneously on same processor.
  • Tasklet is strictly serialized wrt itself, but not wrt another tasklets.
  • Tasklet runs on same CPU from where is raised

Why softIRQ if tasklet is there ?

I’ll explain the need of softirq. That’s the networking code. Say you get a network packet. But to process that packet, it takes a lot of work. If you do that in the interrupt handler, no other interrupts can happen on that IRQ line. That would cause a large latency to incoming interrupts and perhaps you’ll overflow the buffers and drop packets. So the interrupt handler only moves the data off to a network receive queue, and returns. But this packet still needs to be processed right away. Before anything else. So it goes off to a softirq for processing.But Now you still allow for interrupts to come in. Perhaps the network interrupt comes in again on another CPU. The other CPU can start processing that packet with a softirq on that CPU, even before the first packet was done processing. the same tasklet can’t run on two different CPUs, so it doesn’t have this advantage. In fact if a tasklet is scheduled to run on another CPU but is waiting for other tasklets to finish, and you try to schedule the tasklet on a CPU that’s not currently processing tasklets, it will notice that the tasklet is already scheduled to run and not do anything. So tasklets are not so reliable when it comes to latencies.

3. Workqueue

Workqueues are also like tasklets. They are useful to schedule a task that for future. There is some identical difference between  two,

Runs in kenrel process context. Because work queues run in process context (kernel threads), they are capable of sleeping

  • Non atomic execution.
  • Workqueue runs on same CPU from where is raised
  • Higher latency compared to tasklet.

NOTE: This article contains only conceptual details of Interrupt handling mechanism of Linux. 



Filed under interrupts in linux

8 responses to “Concept of ISR in Linux

  1. viswanath

    very nice….

  2. kathiravan

    Y softirq and tasklet are running in interrupt context. Y it cant run in process context like work queue?

    • shah.b

      Linux kernel gives a provision to run bottom half in either kernel process context or interrupt context. Its totally up to the device driver developer, what he/she wants to use. If developer want to execute bottom half as fast as possible in atomic manner then he/she suppose to use tasklet/ softIRQ else workqueue can be used.

  3. gautam

    small doubt: if softIRQ /tasklet runs in interrupt context only then what is the difference between moving the packet handling code from ISR to softIRQ .
    I guess the interrupt context in which original ISR ran and the interrupt context in which softIRQ will run will be different , that you may have missed .

    • shah.b

      Yes, you are right interrupt context in which original ISR ran. As per LDD “tasklets/softIRQ are a special function that may be scheduled to run, in software interrupt context, at a system-determined safe time.” Its not a hard interrupt context. when running in to software interrupt context, your code is subject to a number of constraints.
      1. The Software interrupt context function must be atomic
      2. No access to user space is allowed in software interrupt context
      3. No sleeping or scheduling may be performed

      For hard interrupts kernel guarantees that this handler is never re-entered.In case of software interrupt, it may or may not be re-entered.
      In hard interrupt context, another interrupt arrives, it is queued or dropped. Because it disables interrupts. So this handler has to be fast. Frequently hard interrupt context code simply acknowledges the interrupt, marks a `software interrupt’ for execution and exits.

      On the reception of packet, the hardware interrupt will give the data to softIRQ/tasklet to process the packet exit. So it can immediately receive another packet. Initial processing of packet is done by software interrupt context not hardware interrupt context.

      Hope it is clear now ?

  4. kollurisrinu

    The Corresponding interrupt is disabled during the execution of a interrupt handler.During execution of ISR if other interrupts are came, what will be happen?
    will stop the current ISR and switch over to new ISR?

    kindly explain in detail please …

    Thanks & Regards,

    • shah.b

      During interrupt top half, interrupt on current CPU core is disable.
      If any interrupt comes during this period, then pending IRQ flag in CPU status register will be set.

      After first intrrupt finish its atomic context, kernel check the IRQ pending flag and calls ISR handler registered with pending IRQ number.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s