Concept of Process Scheduling

Starting from this blog, we will go deep into process management and even the core concept of the entire kernel-process scheduling. Here, let's take a look at the relevant concepts.

 

We have just started to talk about Linux. It is a time-sharing system, but it has the characteristics of a real-time system. So like any time-sharing system, a quick switch from one process to another achieves the magical effect of simultaneous execution of multiple processes. We have already talked about process switching in the previous blog. Starting from this blog, we will enter the most important part of process management-process scheduling, the main concern is when to switch the process and select which process to run.

Taking the ULK-3 method as an example, we assume that the system uses the unified memory access model (uniform memory access ), and the system clock is set to 1 ms.

1. Scheduling Policy

Linux scheduling is based on time-sharing ). Let me talk about the connotation of this technology:

Multiple processes run in "time multiplexing" mode, because the CPU time is divided into "slice" and each executable process is allocated one piece. A single processor can run only one process at any given time. If the time slice or time limit (quantum) of the currently running process expires, the process can be switched. Time-sharing depends on scheduled interruption. Specifically, it is the well-known timer_interrupt interrupt service function in the arch/i386/kernel/time. c file we mentioned in the Interrupt Processing topic. Therefore, it is transparent to all processes and no additional code needs to be inserted into the program to ensure CPU time-sharing.

The first reading of this sentence will certainly be puzzled. It doesn't matter. You can understand the specific implementation and then read such general text to understand it. As the pacemaker drives the process scheduling, the scheduling policy also classifies the process based on the priority of the process. Sometimes the current priority of a process is obtained using a complex algorithm, but the final result is the same: each process is associated with a value, which indicates how to properly allocate the process to the CPU.

In Linux, the priority of a process is dynamic. The scheduler tracks what processes are doing and regularly adjusts their priorities. In this way, processes that do not use CPU during a long interval dynamically increase their priority to improve their possibility of being scheduled. Correspondingly, for processes that have been running on the CPU for a long time, they are penalized by reducing their priority.

2. Process Preemption

The next important concept is process preemption.

Linux processes are preemptible. What does it mean? If a process enters the task_running state (usually a process that has just changed to a runable state), the kernel checks its dynamic priority (note that the kernel is determined by the dynamic priority, the user can only set the static priority of the process through system calls.
) Is it higher than the priority of the currently running process. If yes, the current execution is interrupted and the scheduler is called to select another process to run. In another case, a process can also be preemptible when its time slice expires. In this case, the tif_need_resched flag in the thread_info structure of the current process is set so that the scheduler is called when the scheduled interrupt handler ends.

It may not be clear, so let's consider an example: if there are only two programs-one text editor and one kernel process (kswapd) being executed. A text editing program is an interactive program, so its dynamic priority is higher than kswapd. However, the editing program is often suspended because it is alternate between paused thinking and data input. In addition, the average latency between the two keys is relatively long. Therefore, as long as the user presses a key, the interruption occurs, and the kernel wakes up the text editing process. The kernel also determines that the dynamic priority of the editing process is indeed higher than the current priority (the currently running process, that is, kswapd). Therefore, the tif_need_resched flag of the editing process is set, in this way, the scheduling program is activated when the kernel finishes processing the interrupt. The scheduler selects the editing process and executes the process switch. As a result, the editing process quickly resumes execution and displays the characters typed by the user on the screen. When the characters are processed, the text editing process suspends itself and waits for the next press key. kswapd resumes execution.

Note that the preemptible process is not suspended because it is still in the task_running state, but no longer using the CPU. In addition, remember that the linux2.6 kernel is preemptible, which means that the process may be preemptible whether in the kernel or user State.

3 time slice

Let's talk about another concept: time slice.

A time slice is the time that the CPU assigns to a process. In the process descriptor, there is a very important field:
Task-> time_slice

It is the time slice of the process and the remaining clock cycle. We have mentioned many times that the timer interruption is like a pacemaker. Every time the clock is interrupted, it will reduce its cycle and execute scheduling when it is 0.

The length of a time slice is crucial to system performance: it cannot be too long or too short.

If the average time slice is too short, the additional system overhead caused by process switching will become very high. For example, assume that the process switching takes 5 ms. If the time slice is also 5 ms, the CPU will spend at least 50% of the time on the process switching.

If the average time slice is too long, the process does not seem to be executing concurrently. For example, let's assume that the time slice is set to 5 seconds, then each executable process runs for about 5 seconds, however, the pause takes a longer time (typically 5 seconds multiplied by the number of processes that can be run ).

It is usually considered that a long time slice reduces the response time of the interactive application, but this is often wrong. As mentioned in the preceding example, the text editor process-interactive processes have a relatively high priority. Therefore, no matter how long the time slice is, they will quickly seize and process the process.

In some cases, a long time slice will reduce the system's response capability. For example, assume that two users enter two commands at their respective shell prompts, one starting a CPU-restricted process and the other starting an interactive application. Both shells create a new process and delegate the execution of user commands to the new process. In addition, it is assumed that such a new process initially has the same priority (Linux does not know whether the execution process is batch or interactive ). Now, if the scheduler selects a CPU-restricted process for execution, another process may have to wait for a time slice before it starts to execute. Therefore, if such a time slice is long, it seems that the system may be slow to respond to user requests.

The choice of time slice size is always a compromise. Linux uses an experience-based approach, that is, selecting a time slice that is as long as possible and can maintain a good response time.

4 Scheduling Algorithm

The last concept is the core concept of this topic-Scheduling Algorithm

In earlier versions of Linux, the scheduling algorithm is very easy to understand: during each process switchover, the kernel scans the linked list of processes that can run, computes the priority of processes, and then selects the "best" process to run. The main disadvantage of this algorithm is that the time consumed by selecting the "best" process depends on the number of processes that can be run. Therefore, the overhead of this algorithm is too large, in high-end systems running thousands of processes, it takes too much time.

The scheduling algorithm of Linux 2.6 is much more complicated. Through the design, the algorithm better solves the proportional relationship with the number of processes that can run, because it selects the process to run at a fixed time (irrelevant to the number of processes that can run. It also well handles the proportional relationship with the number of processors, because each CPU has its own runable process queue. Moreover, the most important thing is that the new algorithm effectively solves the problem of distinguishing between interactive processes and batch processing processes. Therefore, in a high-load system, users feel that the interaction application response speed in linux2.6 is faster than that in earlier Linux versions.

Each Linux Process is always scheduled according to the following scheduling type: policy field in the task_struct Structure

Sched_fifo

First-in-first-out real-time process. When the scheduler allocates the CPU to a process, it retains the process descriptor at the current position (at the beginning) of the running queue linked list ). If there are no other high-priority real-time processes that can run, the process will continue to use the CPU and how long it will take, even if there are other real-time processes with the same priority in the running status.

Sched_rr

Real-time process of time slice rotation. When the scheduler allocates the CPU to a process, it places the process descriptor at the end of the running queue linked list. This policy ensures that the CPU time is allocated fairly to all sched_rr real-time processes with the same priority.

Sched_normal

The next blog will discuss common time-sharing processes in detail.

The scheduling algorithm varies depending on whether the process policy is a common process or a real-time process. You only need to know the concept here. In the next blog, we will discuss the specific implementation process in detail.