Linux kernel: What you need to know about interrupts

1. The real difference between interrupt handlers and other kernel functions is that the interrupt handlers are broken by the kernel calls, and they run in the interrupt context (atomic context) , and the code executing in that context is not blocked . Interrupts are the hardware that interrupts the operating system.

2. Unlike interrupts, it must be considered synchronized with the processor clock when it is generated. exceptions are referred to as synchronization interrupts , such as: except for 0, a missing pages exception, and a kernel trap that causes system call handler exceptions.

3. Different devices correspond to different interrupts, and each interrupt is identified by a unique number (interrupt number).

4, both want to let the interrupt processing program to run fast, and want to interrupt the processing process to complete a lot of work, in order to achieve a balance between the two conflicting goals, the interruption processing is generally divided into two parts. The interrupt handler is the upper half (top half): An interrupt is received, it starts executing immediately, but only works with strict deadlines, such as answering an accepted interrupt or resetting the hardware, which is done in the case where the interrupt is forbidden (in the case of the upper half, the interrupt is disabled ) The other part is the lower half (bottom half): The work that can be allowed to be done later is postponed to the lower half.

(1) Why use the lower half?

When the interrupt handler executes, the interrupt corresponding to the current interrupt number is masked on all processors, and worse, if the processor program is a irqf_disabled type, it will block all local interrupts when it executes. However, shortening the time to block the interruption is critical to the responsiveness and performance of the system, so we should try to shorten the time to interrupt the process by putting some work into the future. The key is to allow all interrupts to be responded to when running in the lower half .

(2) The reference principle of dividing the upper half and the lower part of the interruption:

• If a task is sensitive to time, put it in an interrupt handler to execute
• If a task is related to hardware, it is executed in the interrupt handler.
• If a task is to ensure that the part is interrupted by another interrupt (especially the same interrupt), it is placed in the interrupt handler for execution.
• All other tasks, consider placing in the lower half of the execution

5, example, network card driver, when the network card received from the network packet, you need to notify the kernel packet to. The interrupt handler (top half) immediately begins execution: Notifies the hardware, copies the latest network data to memory, and then reads more packets from the NIC, which is very urgent because the cache size of the received packets on the NIC is fixed; the lower part: Perform other work to process and manipulate the packets.

6, Linux provides the implementation of the bottom half of the mechanism: (the first half of the implementation mechanism only one: interrupt handler)

In Linux kernel 2.6, the kernel provides three different forms of the bottom-half implementation mechanism: Soft interrupts, tasklet, and work queues. These three mechanisms are introduced from 2.3 onwards. Soft interrupts are relatively small, tasklet is a more common form of the lower half, but Tasklet is based on soft interrupts.

(1) If you want to join a new soft interrupt, you should first ask yourself why you can't do it with Tasklet, there are only two subsystems (network and SCSI) that use soft interrupts directly. Soft interrupts need to be used only when the frequency of execution is high and the continuity is high. If you don't need to scale to multiple processors, then use Tasklet. Tasklet is essentially a soft interrupt, except that multiple instances of the same processor program can no longer run concurrently on multiple processors.

When is the second part called? After the kernel finishes executing the interrupt handler program, the DO_SOFTIRQ () function, and the soft interrupt begins execution of the remaining tasks left to it by the interrupt handler. Most tasklet and soft interrupts are set to pending status in the interrupt handler, so the most recent time an interrupt is returned is the best time to execute DO_SOFTIRQ ().

(2) Tasklet_action () and tasklet_hi_action () are the core of tasklet processing.

(3) KSOFTIRQD worker thread: Each processor has a set of kernel threads that can assist with soft interrupts (and Tasklet), which are assisted by the kernel processes when there are a large number of soft interrupts in the kernel. When a soft interrupt is being executed, it may trigger itself again, and the kernel is currently taking a scenario where the re-triggering soft interrupt is not immediately processed, and when a large number of soft interrupts occur, the kernel wakes up a set of kernel threads (the nice value is 19) to handle the load.

for (;;) {     if (!softirq_pending (CPU))///If there is no soft interrupt, call schedule ()         schedule ();          Set_current_state (task_running);          while (softirq_pending (CPU)) {           do_softirq ();           if (need_resched ())//re-dispatch if necessary, each iteration will be schedule () to allow more important processes to be processed                 schedule ();     }      Set_current_state (task_interruptible);}

(4) Work queue is another way to postpone work tasks, unlike soft interrupts and tasklet. The work queue gives work to a kernel thread to execute-the bottom half is always executed in the context of the process, and most importantly, the work queue allows for rescheduling and even sleep . Therefore, if the deferred task requires sleep, then the work queue is selected, and if the deferred task does not require sleep, then the software interrupt or Tasklet is selected. If you need to use an entity that can be re-dispatched to perform the next half of the current outage, you should use the Task Force column. a task queue is the only implementation mechanism that can run in the context of a process, and only it can sleep (the key is to see if your task requires sleep). Although the action handler for the work queue runs in the context of the process, it does not have access to the user space because the kernel thread does not have a related memory mapping in user space.

Note: The MMC driver uses the Work queue ~

Notice: Typically, when a system call occurs, the kernel runs on behalf of the user-space process, at which point it can access the user space, and only then it maps the memory of the user space.

(5) Selection of the lower half mechanism

Comparison of the lower half mechanism

The lower half of the	Context	Sequential Execution Assurance
Soft interrupt	Interrupt	No
Tasklet	Interrupt	Same type cannot be executed concurrently
Work queue	Process	Not (as the process context is dispatched)

From an ease-of-use perspective: Work queues > Tasklet > Soft interrupts

Summary: Driver writers need to make two choices. First of all, do you need a scheduler to perform the work that needs to be pushed back-fundamentally, do you need to postpone the task to sleep? If so, the work queue is the only option, otherwise it would be better to use Tasklet. Second, if you have to focus on performance improvements, consider a soft break.

(6) When using the lower half mechanism, it is critical to avoid access to shared data even on a single-processor system. The functions that prohibit the lower half have local_bh_disable () and local_bh_enable (), which can only disable and activate the soft interrupts and tasklet of the local processor. Because work queues run in the context of a process and do not involve asynchronous execution, there is no need to prohibit them from being executed.

7, in the driver, to request an interrupt (register interrupt handler)

REQUEST_THREADED_IRQ (unsigned int IRQ, irq_handler_t handler,     irq_handler_t thread_fn,     unsigned long flags, const char *name, void *dev);

  IRQIRQ number to be applied, for ARM systems, the IRQ number is usually defined in the platform-level code, and can sometimes be applied dynamically.

The handler interrupts the service callback function, which runs in the interrupt context and the local interrupt of the CPU is off, so the callback function should simply perform the action that requires a quick response, and the execution time should be as short as possible, and the work of the Thread_ is best left to the following FN callback processing.

THREAD_FN If the parameter is not NULL, the kernel creates a kernel thread for the IRQ, and when the interrupt occurs, if the handler callback return value is Irq_wake_thread, the kernel activates the thread thread in the interrupt, The callback function is called, so the callback function runs in the context of the process, allowing blocking operations .

flags Control The bit flags of the interrupt behavior, irqf_xxxx, for example: irqf_trigger_rising,irqf_trigger_low,irqf_shared, etc., in include/linux/ Defined in Interrupt.h.

The name of the device that requested this interrupt service, as well as the name of the interrupt thread, which can be displayed in the/proc/interrupts file.

Dev When a single IRQ is shared across multiple devices, it acts as a handler parameter to differentiate between devices. When the FREE_IRQ () function is called, the role of Dev is reflected.

8. The type of irq_handler_t is defined as follows:

typedef irqreturn_t  (*irq_handler_t) (int,void*);

A typedef is used to define a function pointer type irq_handler_t, the function prototype return type is irqreturn_t; it receives two parameters of the type int and void*

9, REQUEST_THREADED_IRQ () function can sleep, because REQUEST_THREADED_IRQ ()-->proc_mkdir ()-->proc_create ()-->kmalloc (), and Kmalloc () is able to sleep. Therefore, the function cannot be called in the context of the interrupt.

10. Initialize the hardware first, and then register the interrupt handler to prevent the interrupt handler from executing before the device initialization is complete.

11, FREE_IRQ (): If there is no interrupt handler on the given interrupt line, the handler for the response is unregistered and the disconnection is disabled.

12, interrupt processing program even if you do not do any work, at least need to know the device that caused the interruption, tell it has been interrupted; for complex devices, it may also be necessary to send and receive data in an interrupt processor program, and perform some expansion work. These expanded work was postponed to the lower half (bottom half) as far as possible.

13. Interrupt line and interrupt number are two identical concepts, IRQ

14, the interrupt handler in Linux is no need to re-enter, when a given interrupt handler is executing, the corresponding interrupt number on all processors are masked off; therefore, the same interrupt handler is never called at the same time to handle nested interrupts.

15. Process context: A kernel operating mode where the kernel represents the execution of the process-for example, executing a system call or running a kernel thread. In the context of a process, the current process can be associated with the existing macro. And because the process is connected to the kernel as a process context, the process context can sleep, or the scheduler can be called .

16, interrupt the context: not related to the process, and the current macro is not related, so the interrupt context can not sleep, in the context of the interrupt can not invoke any possible sleep function.

17, interrupt handlers interrupt the execution of other code, so the code in the interrupt context should be concise and fast, separating the work from the interrupt handler as much as possible, and then executing it in the lower part.

18, the interrupt handler stack setting is a kernel configuration item, if any, is 1 page size, that is 4KB

19, the reason to control the interruption system is ultimately the need to provide synchronization. Prevents interrupts from providing protection against concurrent access from other interrupt programs, and also prevents kernel preemption; locks provide protection against concurrent access from other processors (SMP systems need to be considered).

Resources:

• Linux Interrupt Subsystem
  
• Usage of C-language typedef
  
• "Linux kernel design and implementation"
• Linux Interrupt subsystem: SoftIRQ, lower half mechanism
  
• Work queues in Linux