The development of Kernel Learning Scheduler

The main task of the scheduler is to select the most appropriate one in all RUNNING processes. As a general-purpose operating system, the Linux scheduler divides processes into three categories:

Interaction process: Such processes have a large number of human-computer interaction, so the process is constantly asleep, waiting for user input. Typical applications such as the Editor VI. Such processes require high system response times, otherwise users will feel the system is slow to react.

Batch process: Such processes do not require human-computer interaction, run in the background, and require large amounts of system resources. But can endure the response delay. such as compilers.

Real-time processes: Real-time scheduling delays require the highest, these processes often perform very important operations, requiring immediate response and execution. such as video playback software or aircraft flight control system. For real-time processes, the scheduling strategy of FIFO or Round Robin is adopted. For ordinary processes, you need to distinguish between interactivity and batch processing.

Note: Traditional Linux Scheduler increases the priority of interactive applications, allowing them to be scheduled more quickly. The core idea of new dispatchers such as CFS and RSDL is "completely fair". This design concept not only greatly simplifies the code complexity of the scheduler, but also provides a more perfect support for all kinds of scheduling requirements.

History of linux2.4 Scheduler

The scheduler used in Linux2.4.18 uses a priority based design, which is not significantly different from the scheduler released by Linus in 1992. The pick next algorithm for the scheduler is simple: the priority of all processes in runqueue is compared sequentially, and the highest priority process is selected as the next scheduled process. (Runqueue is the queue that holds all ready processes in the Linux kernel). The term pick next is used to refer to the process of picking the next process to be scheduled from all candidate processes.

Each process is assigned a time slice when it is created. The clock interrupt decrements the time slice of the current running process, and when the time slice of the process is exhausted, it must wait for the time slice to be reset for the opportunity to run. The Linux2.4 scheduler ensures that all processes are reassigned only when the time slice of all RUNNING processes is exhausted. This period of time is called a epoch. This design ensures that every process has an opportunity to be implemented.

Real-time processes: the priority of a real-time process is statically set and is always greater than the priority of the normal process. Therefore, a normal process can get scheduling only if there is no real-time process in the runqueue. The real-time process uses two scheduling strategies: Sched_fifo and SCHED_RR.

Common processes: For ordinary processes, dispatchers tend to increase the priority of interactive processes because they require fast user response. The priority of a normal process is primarily determined by the Counter field in the process descriptor (plus the static priority set by Nice).

Note: When all the RUNNING process's time slices are exhausted, the scheduler recalculates the counter values of all processes, including not only the RUNNING process, but also the sleep-state process. The counter of processes that are in a state of sleep are not used up, and when recalculated, their counter values add to these previously unused portions, increasing their priority. Interactive processes are often asleep as they wait for user input, and when they are awakened and enter Runqueue, the CPU is given precedence over other processes. From the user's point of view, the response speed of the interactive process is increased.

This scheduler has the following drawbacks:

Scalability is not good: when the scheduler chooses the process, it needs to traverse the entire runqueue to select the best candidate, so the execution time of the algorithm is proportional to the number of processes. In addition, the time spent on recalculation of counter is linearly increasing as the number of processes in the system increases, and when the number of processes is large, the cost of updating counter operations is very high, resulting in a decrease in overall system performance.

Low scheduling performance on high load systems: 2.4 of the Scheduler has a large time slice allocated to each process, so the scheduler is less efficient on a highly loaded server because the average waiting time for each process is proportional to the size of the time slice.

The optimization of an interactive process is imperfect: the principle of Linux2.4 recognition of interactive processes is based on the assumption that interactive processes are more frequently suspended than batch processes. However, this is often not the case, although some batch processes do not have user interaction, but also frequently IO operations, such as a database engine in the processing of queries often disk IO, although they do not require rapid user response, or increased priority. When such processes are heavily loaded in the system, the response time of the real interactive process is affected.

Insufficient support for real-time processes: The Linux2.4 kernel is not preemptive, and preemption does not occur when the process is in the kernel state, which is not acceptable for real-time applications.