The concept of process scheduling

Starting from this Bo, we will slowly go deep into the process management and even the core concept of the entire kernel-process scheduling inside. Here, first of all the relevant concepts to get a reason.

Just contact Linux, we say, it is a time-sharing system, but by the characteristics of real-time system. So, as with any time-sharing system, a fast switch from one process to another achieves the magical effect of seemingly multiple processes executing simultaneously. We have already talked about the process switching itself in front of the posting, starting with this blog, we will go into the most important part of process management--The scheduling of processes, mainly concerned about when to switch processes and choose which process to run.

Drawing on the ULK-3 approach, in order to be simpler to describe, we still take the 80x86 architecture as an example, especially assuming that the system uses a unified memory access model (uniform Memory access) and that the system clock is set to 1ms.
1 Scheduling Strategy

Linux scheduling is based on time-sharing technology (time-sharing). I'm going to start with a general overview of the technology:

Multiple processes run in "time multiplexing" because the CPU time is divided into "slices (slice)", which is allocated to each of the running processes. A single processor can run only one process at any given time, and process switching can occur if the currently running process's time slice or quantum expires and the process is not finished. Time-Sharing relies on timed outages, specifically the famous Timer_interrupt Interrupt service function in the arch/i386/kernel/time.c file that we talked about in the interrupt processing topic. Therefore, all processes are transparent and there is no need to insert additional code into the program to ensure CPU time-sharing. The first time the

Read this sentence will be puzzled, it does not matter, you can understand the specific implementation, and then read the general text, it is good to understand. Continue to go down, timed interruptions are like pacemakers that drive process scheduling, and scheduling policies also classify them according to the priority level of the process. Sometimes a complex algorithm is used to find the current priority of the process, but the final result is the same: each process is associated with a value that represents how the process is properly allocated to the CPU.

in Linux, the priority of a process is dynamic. The scheduler tracks what processes are doing and periodically adjusts their priority. In this way, processes that do not use CPUs over a long interval of time increase their likelihood of being dispatched by dynamically increasing their priority. Correspondingly, for processes that have been running for a long time on the CPU, they are penalized by reducing their priority.
2 process preemption

The next more important concept of

is process preemption.

The process of Linux is preemptive, what does it mean. If the process enters the task_running state (usually a process that has just become operational), the kernel checks its dynamic precedence (note here that the kernel is judged by its dynamic priority, and that the user can only set the process's static priority through system settings) is greater than the priority of the currently running process. If so, the execution of current is interrupted and the scheduler is invoked to select another process to run. Alternatively, the process can be preempted when its time slice expires. At this point, the tif_need_resched flag in the current process Thread_info structure is set so that the scheduler is invoked when the timer interrupt handler terminates.

may still not be clear, let's consider an example: if there are only two programs-a text-editing program and a kernel process (KSWAPD) are executing. A text editor is an interactive program, so its dynamic precedence is higher than that of KSWAPD. However, because the editor alternates between pause thinking and data entry, it is often suspended and, in addition, the average latency between two keystrokes is relatively long. So, as soon as the user presses a button, the interrupt 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 priority of current (the currently running process, that is, KSWAPD), so the tif_need_resched flag of the editing process is set so that the kernel is forced to activate the scheduler when it finishes processing the interrupt. The scheduler selects the editing process and performs process switching; As a result, the editing process resumes execution quickly and echo the user's words on the screen. When the character is processed, the text-editing process suspends itself and waits for the next keystroke, KSWAPD resumes execution. The

Note that the preempted process is not suspended because it is still in a task_running state, except that the CPU is no longer in use. Also, remember that the Linux2.6 kernel is preemptive, which means that the process can be preempted either in a kernel state or a user state.
3 time slice

A second concept-time slice. A

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

It is the time slice of the process and the remaining clock beats. As we've mentioned many times, a timer interrupt is like a pacemaker, and every time the clock breaks, it's a beat, and it executes the schedule when it's 0.

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

If the average time slice is too short, the system overhead caused by process switching becomes very high. For example, assuming that process switching requires 5ms, and if the time slice is 5ms, then the CPU spends at least 50% of the time on process switching.

If the average time slice is too long, the process does not look like concurrent execution. For example, let's assume that the time slice is set to 5 seconds, and each of the running processes runs for about 5 seconds, but the pause takes longer (typically 5 seconds multiplied by the number of processes that can run).
  
Generally consider long time slices to reduce the response time for interactive applications, but this is often wrong. As mentioned in the previous example, the text editor process-The interactive process has relatively high priority, so no matter how long the time slices are, they will quickly preempt and process the processes.

In some cases, a too long time slice can degrade the system's responsiveness. For example, suppose two users enter two commands at their shell prompt, one to start a CPU-restricted process, and another to start an interactive application. All two shells create a new process and delegate the execution of the user command to the new process. In addition, it is assumed that such a new process would initially have the same priority (Linux does not know beforehand whether the execution process is batch or interactive). Now, if the scheduler chooses a CPU-restricted process to execute, then another process may have to wait for a time slice before it starts executing. Therefore, if such a time slice is longer, it seems that the system may be unresponsive to the user's request. The choice of the

time slice size is always a tradeoff. Linux takes the empirical approach of choosing a time slice that is as long as possible while maintaining a good response time.
4 scheduling algorithm

The final concept is the core concept of our topic--Scheduling algorithm

The scheduling algorithm in earlier Linux versions is straightforward: each time the process switches, the kernel scans the list of processes that run the process, calculates the priority of the process, and then selects the "best" process to run. The main disadvantage of this algorithm is that the time it takes to select the "best" process is related to the number of processes that can be run, so this algorithm is too expensive to consume too much time in a high-end system running thousands of processes.

The Linux 2.6 scheduling algorithm is much more complex. By design, this algorithm can better solve the proportional relationship with the number of running processes, because it is in a fixed time (independent of the number of processes that can be run) to select the process to run. It also handles the proportional relationship to the number of processors, because each CPU has its own running process queue. And, most crucially, the new algorithm solves the problem of distinguishing between interactive processes and batch processing processes. As a result, in a highly loaded system, users are more responsive to interacting applications in Linux2.6 than earlier versions of Linux.

Each Linux process is always scheduled according to the following schedule type: Policy field in each task_struct structure

Sched_fifo

Advanced first out of the real-time process. When the scheduler assigns the CPU to the process, it retains the process descriptor at the current position (the front) of the running queue list. If there are no other high priority real-time processes that can be run, the process continues to use the CPU for as long as it can, even if there are other real-time processes with the same priority in the running state.

Sched_rr

The real-time process of time slice rotation. When the scheduler assigns the CPU to the process, it places the process descriptor at the end of the Run queue list. This strategy guarantees the fair allocation of CPU time to all SCHED_RR real-time processes with the same priority.

Sched_normal

Common time-sharing process, the next blog post will be discussed in detail.

The scheduling algorithm varies according to whether the process strategy is a normal process or a real-time process, as long as you know the concept of the line, the next blog, we will discuss the specific implementation process in detail.

Reprint: http://blog.csdn.net/yunsongice/article/details/5526175