Overview of interrupts, system calls, and schedules for Linux systems "Go"

Transferred from: http://blog.csdn.net/yanlinwang/article/details/8169725

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Recently learning the Linux operating system, about the interrupt system calls and process level always feel a bit vague place, special here to do a summary, tidy up the idea.

The so-called interruption is in the process of computer execution, due to the occurrence of some special things, so that the CPU suspended the execution of the program, in turn to execute the process of handling the event. When these special things are done, go back to the previous procedure. Interrupts are generally divided into three categories: 1, by the computer hardware abnormal or failure caused by the interruption, called internal abnormal interruption, 2, the program is executed by the interrupt caused by the instruction to interrupt, known as soft interrupt (this is also the system call we will explain the related interrupt); 3. Interrupts caused by external device requests are called external interrupts. In short, the understanding of interruptions is the handling of some special things.

A concept that is closely linked to interrupts is the interrupt handler. When interrupts occur, the system needs to process interrupts, and the processing of these interrupts is performed by a specific function in the operating system kernel, which is what we call an interrupt handler for this particular function.

Another concept that is closely linked to interrupts is the priority of interrupts. The priority of the interrupt indicates the level of interrupts that the processor can accept when an interrupt is being processed. The priority of the interrupt also indicates how urgent the interrupt needs to be handled. Each interrupt has a corresponding priority, and when the processor is handling an interrupt, only interrupts that are higher than this interrupt can be accepted by the processor and processed. Interrupts that have a lower priority than the interrupt priority that is currently being processed will be ignored.

The typical interrupt level is shown below

When a software outage occurs, all other interrupts can occur and are processed, but when a disk outage occurs, only clock interrupts and machine error interrupts can be processed.

Before calling the system, let's say that the execution of the process is at two levels on the system: User-level and core-level, also known as user-mode and system-state (kernel mode). The execution of the program is usually performed in the user state, but when the program needs to use the services provided by the operating system, such as opening a device, creating a file, reading and writing files, and so on, it needs to make a request to the operating system to invoke the service, which is the system call. The Linux system has a dedicated library of functions to provide access to these request operating system services, which contain interfaces that the operating system says provides external services. When a process makes a system call, its running state is changed from the user state to the kernel mentality. But at this time, the process itself does not actually do anything, this time the kernel is doing the corresponding operation, to complete the process of these requests.

The relationship between system calls and interrupts is that when a process makes a request for a system call, a software interrupt is generated. When this software interrupt is generated, the system will process the soft interrupt, and the process will be in a nuclear mindset.

So what is the difference between a user state and a nuclear mindset? (The following distinctions are taken to the UNIX operating system design)

1, the user-state process can access their own instructions and data, but not access to the kernel instructions and data (or other process instructions and data). However, processes in the nuclear mindset can access the kernel and user addresses

2, some machine instructions are privileged instructions, the execution of privileged instructions under the user state will cause errors

One understanding of this is that in the system the kernel is not a collection of processes that are parallel to the user process, and the kernel is running for the user process.

How to understand the difference mentioned above, especially the difference 1? To really understand this, you need to have a general understanding of the process's representation in memory.

Each program needs to be loaded (in whole or in part) into memory before it can start running, and in 32-bit machines, each process has a 4G virtual address space. But for this 4G space is not all can be used by the process, in Linux, the 4G space is roughly divided as follows

Therefore, in principle, the virtual address space that the user can use in the process is only 3G. Normally, the user program can only access addresses within this 3g range (and not all addresses, of course) when the user state is running. When the process due to system calls into the nuclear mentality, then the system kernel will do the corresponding operation, it can access its own 1G address space, but also access to 3G of user address space. The data for the instruction of the user process is present in the 3G address space. And, of course, the stack of processes.

Subdivision, a process in memory typically contains the following sections, data segments, instruction segments, run-time heap, stack, and so on. As follows

The kernel's own stack is in the top-level 1G address space, which is the only part that is accessible by the kernel.

Before you talk about process scheduling, start by collating the various states that the process may have. First we know that the running state of the process is divided into core State and user state. Other process states include the following

The process is not executed, but is in a ready state and can be executed as long as the kernel dispatches it

Process is sleeping and in main memory

The process is in a ready state but is in level two memory

Process in sleep, and in level two memory

The process performs a kernel-state operation and is about to return to the user, the kernel does the process dispatch, switches the context

Process has just been created

The process called exit, in a zombie state

The state transitions between processes are as follows, with arrows indicating the direction of the transition

The transitions of the various states of a process are complex, focusing on the two running states of the process, sleep, and transitions from ready to run

As can be seen in the event of an outage or system call, the process is changed from the user state to a kernel mentality. However, the process can not be preempted when the kernel mentality is running, so only when the process is in the state of mind to sleep, or when the process is in the user state, is it allowed to do process scheduling and switch contexts. While the process is in the ready state when the kernel is scheduled to start running, the first is to enter the nuclear mentality.

Why, then, does the process not allow process scheduling when the kernel mentality is running? Because when the kernel mentality is running, you need to access information from some of the global core data structures. If a process is scheduled to run in a kernel state, it will change the process context at the core runtime, and these different process contexts may have different operational requirements for the same core data, which would potentially break the information in the global core data structure. In order to ensure the consistency of kernel core data, context switching is not allowed when the process is in a kernel state of mind.

This involves another problem, where interrupts can occur at any point in time, and the processing of interrupts can affect the consistency of the kernel data. So, how does the process guarantee the consistency of the kernel data in the event of an outage when it is running in a nuclear mindset? The solution is broadly divided into two categories, one that simply disables all interrupts in the nuclear mindset, but reduces the response to interrupts, and the other is to set up a critical section to find out where the kernel data might be inconsistent in the action statement, and then set this part as a critical section. However, when the CPU executes the critical section code, the CPU's execution level is increased so that it can block out a lot of interrupts, thus guaranteeing the consistency of the data. In general, in order to ensure the performance of the system, the critical area is very small, and will not occur frequently.

Overview of interrupts, system calls, and schedules for Linux systems "Go"