Interruption of Linux kernel learning (1)

Linux Kernel learning interruption

[Interrupt overview]

An interrupt is essentially a special electrical signal sent to a processor by a hardware device. The difference between exceptions and interruptions is that exceptions must be synchronized with the CPU clock when they are generated. In fact, exceptions are often called synchronization interruptions. For example, the processor will generate an exception when the system has to rely on the kernel for processing except 0 or missing pages.

 

[Implementation of interrupt handling mechanism]

Interrupt the route from hardware to Kernel

The device generates an interruption and sends an electrical signal to the interrupt controller through the bus. If the disconnection is activated (they allow blocking), the interrupt controller sends the interruption to the processor. In most architectures, this is done by sending a signal to a specific pin of the processor through an electrical signal. Unless the interrupt is disabled on the processor, the processor immediately stops what it is doing, closes the Interrupt System, and jumps to a predetermined location in the memory to start executing the code there. This predefined location is set by the kernel and is the entry point of the interrupt handler.

 

[Interrupt Processing Program]

In response to a specific interrupt, the kernel executes a function called interrupt handler and interrupt service routine ).

The interrupt handler is an ordinary C function, but its real difference with other kernel functions is that the interrupt handler is called by the kernel to respond to the interruption and runs in the interrupt context.

 

Register the interrupt handler:

Static inline int _ must_check

Request_irq (unsigned int IRQ, irq_handler_thandler, unsigned long flags,

Const char * Name, void * Dev)

IRQ: The allocated interrupt number.

Handler: pointer of the interrupt processing function program typedefirqreturn_t (* irq_handler_t) (INT, void *);

Flags: interrupt type

Name: the name of the device associated with the interruption;

Dev: used for shared interruption, because several devices may exist on one interrupted line. Dev is used to identify which device causes the interruption.

 

Comparison of Interrupt context and process context

	Interrupt Context	Process context
Definition	When an interrupt processing program is executed, the kernel is in the interrupt Context	When a program calls a system call or triggers an exception, it falls into the kernel space. At this time, the kernel indicates that the process is executed and in the context of the process.
Sleep	Sleep is not allowed and cannot be scheduled. That is to say, functions with potential sleep cannot be used to interrupt context.	Sleep and Scheduling
Synchronization Mechanism	Spin lock	Yes

 

[Interrupt the upper half and lower half]

First, ask yourself a question. Why should we divide the interrupt into the upper half and the lower half? Isn't it good to put one in the interrupt processing program? The answer is no.

The division of interruptions solves the problem that we want to interrupt the processing program to run fast, but also to interrupt the processing program to complete a lot of work.

1. interruption can interrupt other programs that are being executed at any time. If the interrupted code is very important to the system, the shorter the execution time of the interrupt handler, the better;

2. When the Interrupt Processing Program is being executed, the interrupt requests of the same interrupt line will be blocked. What's more serious is that if ir1__disabled is set, all other interrupt requests will be blocked when the interrupted service program is executed. The faster the interrupt handler is executed, the better.

Upper Half: a fast, asynchronous, and simple processing program is dedicated to responding to hardware interrupt requests quickly. At the same time, some time-demanding operations must be completed;

Lower half: the time requirement is relatively loose, and other remaining work will be executed at any time later.

The following is the division of the upper half and lower half:

If a task is sensitive to time, it will be executed in the interrupt handler;

If a task is related to hardware, place it in the interrupt handler for execution;

To ensure that a task is not interrupted by other interruptions (especially the same interruptions), place it in the Interrupt Processing Program for execution;

All other tasks should be considered for execution in the lower half.

 

[Lower half mechanism]

Soft Interrupt

The Soft Interrupt is retained to the lower half of the system with the strictest time requirements and the most important. Currently, only two subsystems (network and SCSI) use the Soft Interrupt directly.

 

Tasklet

Tasklet is a lower half Mechanism Implemented by Soft Interrupt. When you choose to use soft interrupt or tasklet, we recommend that you use tasklet, in addition to network and SCSI conditions. Compared with Soft Interrupt, The tasklet interface is simpler and has lower lock protection requirements.

 

Work queue

A work queue can forward the work to a kernel thread for execution. The lower half is always executed in the context of the process, allowing rescheduling and sleep.

 

Comparison of Three lower half mechanisms

Lower half	Context	Sequential execution assurance
Soft Interrupt	Interrupted	No
Tasklet	Interrupted	The same type cannot be executed simultaneously
Work queue	Process	No (scheduled like process context)