This article mainly discusses the process scheduling algorithm on a single processor. Before discussing the specific algorithm, it is assumed that there is a specific operating system such as pkzd.
Assuming that the system pkzd does not have preemptive process scheduling, then we consider the next situation:
Assuming that there are processes p1, p2, and p3 in the memory at the same time (for convenience, the process of swapping out is not discussed here), the running times of p1, p2, and p3 are 10ms, 100ms, and 1000ms, respectively. If the system runs the processes in sequence, then the average The waiting time is about 40ms. If the process arrives in the order p3, p2, p1, then the average waiting time is about 370ms. There is a huge gap in the average waiting time of the process because of the order in which the processes arrive. What's more, if there is a process whose running time is infinite, it will occupy all the CPU time, which is obviously unreasonable, so it must be introduced A mechanism to guarantee fair scheduling. Note: There are many scheduling algorithms in non-preemptive systems. Some algorithms can reduce the gap between the average waiting times caused by different process arrival sequences, but some algorithms are not very simple to implement, such as the SJF algorithm. In addition, all non-preemptive systems cannot handle processes that never terminate well (for example, there are many infinite loops in the system).
The goal of process scheduling in a single processor is to allow all processes to distribute CPU time fairly. Let's discuss one of the more ancient and simple methods:
RR algorithm, the main idea of this algorithm is to allocate a time slice to all processes. A process occupies at most one time slice. Once the time slice is used up, other processes must be called. The algorithm can be implemented with a linked list (of course, this is not the best way to implement it, and it is not necessarily the easiest. The reason for using a linked list is just because I think it is easier to use a linked list, but you don't necessarily think so):
head---p1----p2---p3------pn
There are processes p1, p2, assuming that the p1 process is a running shell, and p2 is a brute force program (may run for a few days). First, the kernel calls the process p1, because the user did not input any data on the keyboard, so p1 fell into sleep after running for 1ns, and then the kernel called p2 to run, after running for a period of time (because p1 is in sleep, the running program is always p2), the user Enter some characters (maybe a command ls), then the kernel wakes up the process p1, waits for the time slice of p2 to end, then calls p1, and p1 continues to sleep after executing the command ls (the execution time is assumed to be 1ms). The kernel keeps calling p1 and p2 over and over again. You may have found that in this case, the CPU time occupied by p2 will be much larger than that of p1, which is obviously unfair. In addition, for interactive systems, users always want to get a response when pressing a key, and users usually don't care whether the background process is running, so it is generally believed that the interactive process should get a higher priority so that it can be scheduled as soon as possible.
head points to the head of the process linked list, p1, p2 to pn represent the process. Assume that the operating system allocates a fixed time slice of 10ms to each process (Note: The size of this value will have a great impact on the performance of the entire operating system in a system using the RR algorithm, and the setting of this value must be careful , the last 10ms is a good value for the time slice size that can be considered), then the kernel first calls the process p1, after running for a period of time (less than or equal to 10ms, if the process p1 is blocked on an event, then the running event will be less than 10ms, An extreme case may be a few ns), the kernel adds p1 to the tail of the process linked list, and resets the time slice of process p1 to 10ms, and then the kernel continues to call process p2, so that the kernel keeps calling different processes to ensure fair.
The RR algorithm simply and effectively implements a fair scheduling mechanism, but there are some problems with this algorithm, such as the following:
An improved mechanism is to add priority. The implementation method may be to classify all processes according to priority, such as the process waiting for keyboard input into I/O-like characters, the waiting for memory into the class mem, and the waiting for disk. Put it in the class I/O block, each time the kernel schedules, it starts from the I/0 character class (the processes of this class are generally related to the soul, so it has a higher priority) to find the process that can run. If not, go to the next class to find, and finally if there is no runnable process in all classes, the kernel finds an idle process from the idle class and runs it. Classifying all processes allows I/O-intensive processes to wait more fairly, and because I/O-intensive processes sleep most of the time, CPU-intensive processes are also treated better. However, there are also problems with this implementation:
Consider the following situation, the operating system has 100,000 processes, 50,000 I/O-intensive processes, and 50,000 CPU-intensive processes, then there may be a situation where the kernel will always schedule processes from the I/O class and not Move into the cpu class, so 50,000 processes will be unfairly opposed, and may never be run. In this case, a possible improvement method is to add some count variables to observe all process classes, and when the kernel is about to schedule processes, the kernel selects the appropriate class according to the count variables (such as the total CPU occupied by the processes in the class). number, number of processes, number of schedules, etc.), of course this would be a complex implementation.
Next, I will explain the scheduling mechanism of linux. Unlike the general time slice scheduling algorithm, linux uses a proportional method to allocate time slices to all processes. Scheduling (although its guarantees will no longer be valid when the number of processes explodes).
As for thread scheduling, this is a more complicated topic, and a short-answer example, whether to treat threads of different processes equally is a question worth considering, because the number of words in this article is limited and will not be discussed.
最后，调度算法对整个操作系统的性能会产生很大的影响，并且对于不同的进程，内核如何差别对待并且保证公平也是个值得考虑的问题，比如PC上的交互式进程一般情况应该比cpu密集的进程获得更多的调度机会，而一些特殊的情况，比如一个核武器的演算进程应该比一个交互进程获得更多的cpu才对。不管如何调度机制要保证的是所有的进程被公平的对待，对于I/O密集的进程应该保证其运行时间而给予更多的调度次数，而cpu密集的进程应该适当的减少其调度次数来减少其占用cpu的时间。