- During interrupt processing, process switching should not occur, because in the interrupt context, the only thing that can interrupt the current interrupt handler is the higher priority interrupt, which will not be interrupted by the process (this is the same for softirq and tasklet Therefore, these bottom half cannot sleep.) If you sleep in the interrupt context, there is no way to wake it up, because all wake_up_xxx is for a certain process, and in the interrupt context, there is no concept of a process, no task_struct (This is the same for softirq and tasklet), so it really sleeps, such as calling a routine that will cause a block, the kernel will almost certainly die.
2. Schedule () saves the current process context (CPU register value, process status, and contents of the stack) when switching processes, so that this process can be resumed later. After an interrupt occurs, the kernel will first save the currently interrupted process context (recovered after calling the interrupt handler); but in the interrupt handler, the value of the CPU register must have changed (the most important program counter PC, stack SP Etc.) If schedule () is called at this time because of sleep or blocking operations, the saved process context is not the current process context. Therefore, it is not possible to call schedule () in an interrupt handler.
3. The interrupt handler will use the interrupted process kernel stack, but it will not have any impact on it, because after the handler is used, it will completely clear the part of the stack it uses and restore the original appearance before being interrupted.
4. When the context is interrupted, the kernel is not preemptible, so if it sleeps, the kernel must hang.
If the interrupt can sleep, it will cause a lot of problems. For example, if you sleep in a clock interrupt, the operating system clock will be chaotic, and the scheduler will lose its basis; for example, you will be interrupted in an IPI (interprocessor ), The other CPUs are waiting for your reply in an endless loop, you do sleep, then the other processors are not working; for example, you sleep in a DMA interrupt, the above process is still synchronously waiting for I / O When completed, the performance is greatly reduced ... There are many examples. Therefore, interruption is an urgent matter that needs to be handled by the operating system immediately, not because it cannot sleep, but because it has no reason to sleep.
Transfer from: Why the interrupt can not sleep
