Process context VS interrupt Context

Process context VS interrupt context kernel space and user space are two working modes of modern operating systems. kernel modules run in kernel space, while user-Mode Applications run in user space. They represent different levels and have different access permissions to system resources. The kernel module runs at the highest level (kernel state). All operations at this level are trusted by the system, while application programs run at a lower level (User State ). At this level, the processor controls direct access to hardware and unauthorized access to memory. The kernel state and user State have their own memory ing, that is, their own address space. The www.2cto.com processor is always in one of the following States: 1. the kernel state runs in the process context. The kernel indicates that the process runs in the kernel space. 2. The kernel state runs in the interrupt context, the kernel indicates that the hardware runs in the kernel space. 3. The user State is run in the user space. The user space application enters the kernel space through the system call. The kernel indicates that the process runs in the kernel space, which involves context switching. The user space and the kernel space have different address ing, general or dedicated register groups, the user space processes need to pass a lot of variables and parameters to the kernel. The kernel also needs to save some registers and variables of the user process so that the system can return to the user space for further execution after the call is completed. The so-called "process context" refers to the value in all the registers of the CPU, the status of the process, and the content on the stack when a process is executed. When the kernel needs to switch to another process, it needs to save all the statuses of the current process, that is, to save the context of the current process, so that when the process is re-executed, it can restore the status of the switch and continue to execute. The hardware calls the interrupt handler through the trigger signal and enters the kernel space. In this process, some hardware variables and parameters must also be passed to the kernel. The kernel uses these parameters for interrupt processing. The so-called "interrupt context" of www.2cto.com can also be regarded as the parameters passed by the hardware and other environments to be saved by the kernel (mainly the process environment currently interrupted ). When a process is executed, the values in all the registers of the CPU, the status of the process, and the content in the stack are called the context of the process. When the kernel needs to switch to another process, it needs to save all the statuses of the current process, that is, the context of the current process, so that when the process is re-executed, the status of the switch must be executed. In LINUX, the current process context is stored in the task data structure of the process. In the event of interruption, the kernel executes the interrupt service routine in the kernel state in the context of the interrupted process. However, all required resources are retained to resume the execution of interrupted processes when the relay service ends. The Linux kernel works in the process context or interrupt context. The kernel code that provides the system call service indicates that the application initiating the system call runs in the process context; on the other hand, the interrupt processing program runs asynchronously in the interrupt context. The interrupt context is irrelevant to a specific process. Context: the context is simply an environment, which is the environment when the process is executed. Specifically, it refers to various variables and data, including all register variables, files opened by processes, and memory information. The context of a process can be divided into three parts: user-level context, register context, and system-level context. User-level context: body, Data, user stack, and shared storage area; register context: General Register, program register (IP), processor Status Register (EFLAGS), stack pointer (ESP ); system-level context: Process Control Block task_struct, memory management information (mm_struct, vm_area_struct, pgd, and pte), and kernel stack. When a process is scheduled, context switch is used for process switching. The operating system must switch all the information mentioned above before the newly scheduled process can run. The system calls mode switch ). Compared with process switching, mode switching is much easier and saves time, because the main task of mode switching is to switch the context of the process register. Process context mainly involves exception handlers and kernel threads. The kernel enters the process context because some work of the process needs to be done in the kernel. For example, a system call serves the current process, and an exception is usually an error state caused by processing the process. So it makes sense to reference current in the process context. The kernel enters the interrupt context because of the interrupt signal. The interrupt signal is random. The interrupt processing program and Soft Interrupt cannot predict which process is currently running in advance. Therefore, you can reference current in the interrupt context, but it does not make sense. In fact, the interruption signal that process A wants to wait may occur during the execution of process B. For example, process A starts the write operation on the disk, and process B is running after process A is sleeping. After the disk is written, the disk interruption signal interrupts process B, and process A is awakened during the process of interruption. The kernel can be in two contexts: process context and interrupt context. After the system call, the user application enters the kernel space, and then the representatives of the corresponding processes in the user space run in the process context. Asynchronous interruptions may cause the interrupt handler to be called, and the interrupt handler runs in the interrupt context. The interrupt context and process context cannot occur simultaneously. The kernel code running in the process context can be preemptible, but the interrupt context will continue to run until the end, and will not be preemptible. Therefore, the kernel restricts the interruption of context work and does not allow it to perform the following operations: (1) enter the sleep state or voluntarily discard the CPU; because the interruption context does not belong to any process, it has nothing to do with current (although current points to the interrupted process at this time), once the interrupted context is sleep or the CPU is abandoned, it will not be awakened. It is also called the atomic context ). (2) The mutex is occupied. To protect the resource in the critical section of the interrupt handle, mutexes cannot be used. If the semaphore is not obtained, the code will sleep and produce the same situation as above. If the lock must be used, use the spinlock. (3) Execution of time-consuming tasks; interrupt processing should be as fast as possible, because the kernel needs to respond to a large number of services and requests, the interruption context occupies too long CPU time will seriously affect system functions. When executing time-consuming tasks in the Interrupt Processing routine, it should be handled by the bottom half of the interrupt processing routine. (4) access user space virtual memory. Because the interrupt context is irrelevant to a specific process, it indicates that the hardware runs in the kernel space, so the virtual address of the user space cannot be accessed in the interrupt context (5) the Interrupt Processing routine should not be set to reentrant (a routine that can be called in parallel or recursively ). When the interrupt occurs, both preempt and irq are disable until the interrupt is returned. The interrupt context and process context are different. Different instances of the interrupt processing routine cannot run concurrently on SMP. (6) interrupt processing routines can be interrupted by more advanced IRQ. If you want to disable the interrupt, you can define the interrupt processing routine as a fast processing routine, which is equivalent to telling the CPU that all interrupt requests on the local CPU are prohibited when the routine is running. This directly results in a system performance degradation due to delays in response to other interruptions.