The interrupt processing of the Linux kernel runs through the & quot; important tasks immediately, and the unimportant tasks are pushed back to the & quot; asynchronous processing idea: interrupt processing of the Linux kernel, there is an asynchronous processing idea in which everything goes through the process of "doing important things right away, pushing unimportant things back and doing. so sort it out ~
Phase 1 -- get the interrupt number
Each CPU has the ability to respond to interruptions, and each CPU follows the same process in response to interruptions. this process is the interrupt service program provided by the kernel.
When you enter the interrupted service program, the CPU has automatically disabled the interrupt response on the current CPU, because the CPU cannot assume that the interrupted service program can be reentrant.
The first step to interrupt the processing program is to do two things:
1. press the interrupt number into the stack. (different interrupt numbers correspond to different interrupt service program portals)
2. press the current register information into the stack. (this can be restored upon interruption and exit)
Obviously, these two steps are not reentrant (if the register value is interrupted when it is saved, another operation is likely to rewrite the register, and the field will not be able to recover ), therefore, when the CPU enters the interrupted service program, it must be automatically disabled.
The information on the stack is used as a function parameter to call the do_IRQ function.
Phase 2-serialization of interruptions
Go to the do_IRQ function, and perform the serialization of the interrupt in the first step. serialize a certain interruption generated by multiple CPUs at the same time. if the current interrupt is in the "execution" status (indicating that another CPU is processing the same interrupt), reset its "trigger" tag and return immediately. after the CPU that is processing the same interrupt completes a processing, it checks the "trigger" mark again. if it is set, it triggers the processing again.
Therefore, interrupt processing is a loop process. handle_IRQ_event is called cyclically to process the interrupt.
Stage 3: interrupt handling under Guanzhong disconnection conditions
Go to the handle_IRQ_event function and call the interrupt processing function registered by the corresponding kernel or kernel module through the request_irq function.
The registered interrupt handler has an interrupt switch attribute. Generally, the interrupt handler is always disconnected. when you call request_irq to register an interrupt handler, you can also set the interrupt handler to enable the interrupt handler. this is rare because the interrupt handler code must be reentrant. (In addition, if an interrupt is enabled, the interrupt being processed will also be blocked. when an interrupt is being processed, the interrupt on the hardware interrupt controller is not hacked, and the hardware will not initiate the same interrupt next time .)
The process of interrupting the processing function may be long. if the entire process is interrupted, the subsequent interruption will be blocked for a long time.
So, with soft_irq. complete part of the non-reentrant in the interrupt handler (Guanzhong disconnected), and then call raise_softirq to set a soft interrupt. the interrupt handler ends. the subsequent work will be done in soft_irq.
Stage 4: soft interrupt under open interrupt conditions
After calling all the currently triggered interrupt processing functions in the previous stage, the do_softirq function is called to start processing software interruptions.
In the soft interrupt mechanism, a number of bit mask sets are maintained for each CPU. Each mask represents an interrupt number. in the last phase of the interrupt processing function, the corresponding soft interrupt is set when raise_softirq is called. here, the corresponding soft interrupt processing function is called (the processing function is registered by the open_softirq function ).
It can be seen that the soft interrupt model is similar to the interrupt model. each CPU has a set of interrupt numbers, and the interrupt has a corresponding priority. each CPU processes its own interrupt. the biggest difference is the disconnection and disconnection.
Therefore, an interrupt processing process is divided into two parts: the first part is disconnected in the interrupt processing function, and the second part is interrupted in the soft interrupt processing function.
Because this step is implemented under the conditions of an on-going interruption, there may be a new interrupt (Interrupt nesting), and the corresponding interrupt processing of the new on-going interruption will start a new first phase ~ Stage 3. In this third phase, new soft interruptions may be triggered. However, this new interrupt processing process does not enter the fourth stage, but when it finds itself a nested interrupt, it will exit after the third stage is completed. That is to say, only the first-level interrupt processing will enter the fourth stage, and the nested interrupt processing process will only be executed in the third stage.
However, the nested interrupt processing process may also trigger soft interruptions. Therefore, the first interrupt processing process must be a loop in the fourth stage, and all soft interruptions in the nested process must be processed cyclically. Why? In this way, these soft interruptions can be executed in the order in which soft interruptions are triggered. Otherwise, the soft interruptions may be executed first.
In extreme cases, nesting may cause many soft interruptions, and it may take a long time to complete all the processing. Therefore, after the kernel finishes processing a certain number of soft interruptions, push the remaining soft interruptions to a kernel thread named ksoftirqd for processing, and end the interrupt processing process.
Stage 5: enable tasklet under interrupt conditions
In fact, soft interruptions are rarely used directly. in the case of separate interruptions in the second part, the handling process is generally completed by the tasklet mechanism.
Tasklet is derived from soft interrupt. the kernel defines two soft interrupt masks HI_SOFTIRQ and TASKLET_SOFTIRQ (the two have different priorities). the soft interrupt handler corresponding to the two masks acts as the entry to go to the tasklet processing process.
Therefore, in the interrupt processing function of the third stage, after the disconnection is completed, tasklet_schedule/tasklet_hi_schedule is called to mark a tasklet, and the interrupt processing program ends. the subsequent work is handled by the soft interrupt handler corresponding to HI_SOFTIRQ/TASKLET_SOFTIRQ to process the marked tasklet (each tasklet has a handler set during its initialization ).
It seems that tasklet is only called on the basis of softirq. what is its role? As mentioned above, softirq corresponds to the CPU, and each CPU processes its own softirq. these softirq processing functions need to be designed to be reentrant, because they may run simultaneously on multiple CPUs. tasklet is serialized among multiple CPUs, and its processing functions do not have to be reentrant.
However, softirq still has less detours than tasklet, so a few processing processes with relatively high real-time requirements still use softirq after careful design. for example, the process of clock interruption processing, network sending/receiving processing.
End stage
After the CPU receives the interrupt, the interrupt processing is completed in the above five stages. Finally, the Register information stored on the stack in the first stage needs to be restored. the interrupt processing ends.
About scheduling
In the above process, a problem is also implied, and the entire processing process is constantly occupying the CPU (except for the possibility of being interrupted by a new interrupt ). in addition, during the several stages of interrupt processing, the program cannot let out the CPU!
This is determined by the kernel design. the interrupt service program does not have its own task structure (the process control block mentioned in the operating system textbook), so it cannot be scheduled by the kernel. generally, a process gets the CPU out. if a certain condition is met later, the kernel will find it through its task structure and schedule its operation.
There may be two problems:
1. continuous low-priority interruptions may occupy the CPU continuously, while some processes with high priority cannot obtain the CPU;
2. during these stages of interrupt processing, functions that may cause sleep (including memory allocation) cannot be called );
For the first problem, the ksoftirqd kernel thread is added to the new Linux kernel. if the number of softirq continuously processed exceeds a certain number, the process of interruption is terminated, and ksoftirqd is awakened to continue processing. although softirq may be pushed back to the ksoftirqd kernel thread for processing, it still cannot be sleep during softirq processing, because softirq cannot be processed in the ksoftirqd kernel thread.
It is said that the kernel interrupt mechanism has been modified in montavista (an embedded real-time linux. the interrupt processing process is assigned the task structure and can be scheduled by the kernel. solved the above two problems. (The goal of montavista is to ensure real-time performance. this method sacrifices the overall performance .)
Work queue
The linux baseline kernel provides the workqueue mechanism to solve the preceding problems.
Define a work structure (including the processing function), and then call the schedule_work function in a step of several stages of the above interrupt processing, the work will be added to the workqueue, waiting for processing.
The work queue has its own processing thread, which is postponed to these threads for processing. the processing process may only happen in these work threads, so you can sleep here.
The kernel starts a working queue by default, corresponding to a group of working threads events/n (n indicates the processor number, such threads have n ). the driver can directly add tasks to the work queue. some drivers may also create and use their own work queues.
