Linux exceptions and kernel preemption

(1) concept of exceptions
Interrupt signals are collectively referred to as the events that change the execution sequence of CPU commands. However, it can be divided into two types:
One is synchronous, not so sudden, because it only happens after the execution of an instruction is terminated. The book follows Intel's convention, which is called exception ). Generally it is a programming error (generally sending a signal) or an exception that the kernel must handle (the kernel will take some steps required to recover the exception );
One is asynchronous, suddenly, because it is generated by the interval timer and I/O device and only follows the CPU clock signal, so it may be generated at any time, the book also complies with Intel's practice, called interrupt ). The exception types are as follows:

(2) kernel control path
Before the kernel permits the arrival of Interrupt signals, it must first prepare the processing for them, that is, initialize the Interrupt Descriptor Table (Interrupt Descriptor Table, IDT) as appropriate ). When the interrupt signal is sent, the CPU control unit automatically saves the current program counters (EIP, CS) and eflags to the kernel stack, then, the address of the processing program associated with the interrupt signal type (stored in IDT) is put into the program counter. At this time, the kernel control path is born.
What is the kernel control path? Is it a process? No. Kernel process? No. Although it also needs to switch the context, it needs to save the registers it may use and restore it when it returns, but this is a very light context switch (terminal context ). When it was born, there was no process switching. The subject of the process to handle the interruption was still the process being executed when the interruption occurred, and it was still using the time slice allocated to it.
Interestingly, if a process is still processing an exception and the time slice assigned to it expires, what will happen? This depends on whether kernel preemption is enabled. If kernel preemption is not enabled, the process continues to handle exceptions. If kernel preemption is enabled, the process may be immediately preemptible and the exception handling will be suspended, it is not until Schedule () selects the original process again (Note: kernel preemption will be disabled when the kernel is interrupted, so it is abnormal here ).

(3) Constraints on interrupt signal processing
Interrupt signal processing must meet the following three strict constraints:
1) interrupt handling should be completed and returned as much as possible. Therefore, we only need to execute the key and urgent part, and try to mark as many subsequent processes as possible, and then execute them later.
2) When an interrupt is still being processed, another interrupt may come again. In this case, it is best to handle it first, and then handle the new interrupt first, then, we can continue to process the interrupt. This is called the nested execution of the interrupt and exception handling program, or the nested execution of the kernel control path. To achieve this, one thing must be met, that is, the process cannot be blocked during the interrupt processing program running and cannot be switched.
3) There are some critical partitions in the kernel. In these critical partitions, interruption must be disabled. The interrupt handler should minimize the number and time of entry into the critical section. In order to respond to the kernel performance, the interrupt should be enabled most of the time.
(4) IRQ (interrupt request) line (IRQ vector) Allocation
IRQ sharing: several devices share an IRQ. when the device is interrupted, the interrupt service routine (interrupt service routine, ISR) of each device is executed to check whether it is related to itself;
Dynamic IRQ allocation: IRQ can be associated with a device only when a device is used, so that the same IRQ can be used by different devices at different times.

(5) who will do the delayed work?
First, there are two non-urgent and disruptive kernel functions-the deferrable functions function, and then the functions executed through the work queue.

(6) softirq)

It is a reentrant function and must use a spin lock to protect its data structure. tasklet is implemented based on soft interruptions, but because the kernel ensures that the same type of tasklet is not run on both CPUs at the same time, so it does not have to be reentrant. As follows:

(6) kernel preemption)
In the case of non-preemptible kernel, a process in the kernel state cannot be replaced by another process (process switching). In the case of preemptible kernel, it is possible: however, the kernel can be preemptible only when the kernel is executing an exception handler (especially a system call) and kernel preemption is not explicitly disabled.
An example: When a is handling exceptions, an interrupted handler wakes up B with a higher priority. In the case of kernel preemption, a mandatory process switchover occurs. This aims to reduce the dispatch latency, that is, the interval from the process (End Blocking) to the executable state to the actual start of running, reduces the risk that it is delayed by another process running in the kernel state.

 

Http://utensil.javaeye.com/blog/409785 ()