Process scheduling strategy
We call the processes running in the system a workload. The more general our assumptions about workloads are, the more optimal the performance of the scheduling strategy designed based on this assumption.
The following discussion assumes that the workload only occupies the CPU and does not issue any I/O operations.
Scheduling index
Scheduling indicators are used to measure the pros and cons of different scheduling strategies
-
Turnaround time
It is the time it takes for a task to pass to the operating system to the end of its operation.
Work turnaround time = work completion time-work arrival time
This indicator mainly looks at the average turnaround time : the average value of the turnaround time of multiple tasks over a period of time.
Average Turnaround Time = Sum of Turnover Time/Number of Work
-
Response time (response time)
It is the time it takes for a task to be handed over to the operating system to start running (the operating system responds to the task).
Work response time = work first run time-work arrival time
This indicator mainly looks at the average response time : the average of the response time of multiple tasks over a period of time.
Average response time = sum of response time / number of jobs
Optimize average turnaround time
First in first out (FIFO, FCFS)
First In First Out (First In First Out) or First Come First Served
The idea is very simple, that is, whoever comes first will be executed first (until the end of the job).
Under this strategy, after each task arrives, it needs to wait for the previous tasks to be completed before getting a response, and its turnaround time depends on the execution time of the work that arrived first.
Assuming that the three processes of abc arrive at the same time one after another, and the running time is known, they are abc respectively.
Average turnaround time = [a + (a + b) + (a + b + c)] / 3 = (3a + 2b + c) / 3
Average response time = [0 + a + (a + b)] / 3 = (2a + b) / 3
Regardless of the indicator, this strategy is not well optimized for the convoy effect (queuing water problem).
The shortest task first (SJF, SPN)
Shortest Job First or Shortest Process Next
This strategy is a first-in, first-out strategy that takes into account the escort effect. For multiple tasks that arrive at the same time, the task with the shortest time is given priority (greedy).
Assuming that the three processes of abc arrive at the same time one after another, and the running time is known, they are abc respectively.
Average turnaround time = [a + (a + b) + (a + b + c)] / 3 = (3a + 2b + c) / 3
Average response time = [0 + a + (a + b)] / 3 = (2a + b) / 3
This strategy considers the escort effect, but it is only optimized for each group of tasks that arrive at the same time.
If the task a arrives first, bc arrives after the execution of the strategy ends, and there is no difference between the first-in first-out strategy at this time:
This problem can be solved if the shorter time-consuming tasks arriving later can directly preempt the CPU.
Preemptive shortest task first (PSJF, STCF)
Preemptive Shortest Job First or Shortest Time-to-Completion First
The preemptive SJF considers the escort effect completely immediately.
Suppose that the a process arrives first, and the bc process arrives at the same time one after another, and the running time is known, respectively abc.
Average turnaround time = [a + (a + b) + (a + b + c)] / 3 = (3a + 2b + c) / 3
Average response time = [0 + a + (a + b)] / 3 = (2a + b) / 3
For the turnaround time, if the turnaround time of all jobs is known, this is the optimal scheduling algorithm.
However, we still have a scheduling indicator to discuss, the average response time.
Average turnaround time and average response time are like fish and bear's paws. The two are incompatible. Let's take a look at the Round-Robin strategy that optimizes the average response time.
Optimize average response time
Rotation (RR)
It can be called round robin or polling .
Rotation is a fair strategy. It runs a job in a time slice (or scheduling quantum) , and switches to the next job in the queue in the next time slice, and so on. Until all tasks are over.
Suppose a time slice is t, abc arrives one after another at the same time, and the running time is known, respectively, abc.
[External link image transfer failed. The source site may have an anti-hotlinking mechanism. It is recommended to save the image and upload it directly (img-4OUVBKmF-1610107587742)(C:\Users\10199\AppData\Roaming\Typora\typora-user-images\ image-20210107155028268.png)]
Average turnaround time = [(a + b + c) + t + (a + b + c) + (a + b + c)-t] / 3 = a + b + c
Average response time = [0 + t + 2t] / 3 = t
Under this fair strategy, any process has a chance to get a response quickly. The average response time is quite ideal, but the average turnaround time is the sum of the running time of all tasks. The performance is very bad, even worse than FIFO. In fact, any fair strategy will lead to poor performance in turnaround time, and you cannot have both.
In addition, the operation of switching context also requires a certain amount of overhead. Too frequent switching will bring unnecessary performance loss. Reasonably extend the time slice to amortize the context switching cost and ensure that the system responds in time.
However, it is definitely a wise choice to constantly switch the context. Shortening the response time allows the operator to more accurately grasp the machine status and improve the utilization rate of the system (to make people feel happy).
Another advantage of the RR idea is to improve CPU utilization when combined with I/O.
Let another process preempt the CPU while waiting for an I/O device.
Multi-level feedback queue (MLFQ)
The scheduling strategies just discussed are based on an ideal major premise-the operating system accurately understands the length of each job. In fact, the operating system knows very little about this.
So what we will discuss next is:
"How to design a scheduler with predictive ability to approximate the excellent performance of SJF and PSJF in the average turnaround time?"
We also need to combine RR to get a good average response time.
Brief introduction
Multi-level Feedback Queue
This strategy has a series of queues, each queue can have multiple jobs, and different queues have different priorities.
Then, the scheduler always executes the tasks in the high priority queue in turn.
Since we want to achieve the effect of PSJF, short jobs are executed first in PSJF. Correspondingly, in MLFQ, high-priority jobs will be executed first, which means that high-priority jobs are regarded as short jobs by the operating system, that is , the higher the priority of a process, the better its historical performance Acts close to short jobs .
That being the case, how do we predict the behavior of a job and determine its priority?
The basic idea is that when a job enters the operating system, we assume it is a short job or I/O-intensive (interactive) job and give it the highest priority. If it is indeed a short job, it will be executed soon, otherwise it may be a long job or a CPU-intensive job, and it will be gradually moved to a lower priority queue .
rule
In MLFQ, the priority of the process is not static. The scheduler constantly adjusts the priority of each work in real time according to several rules.
We first assume that a job is a short, interactive job.
Rule 1: When work enters the operating system, it is placed in the highest priority queue.
If the execution time of this job is too long, then it is likely to be a CPU-intensive job that takes a long time, so there is rule two.
Rule 2: Once the work runs out of time in a certain priority, the priority is lowered.
If short, interactive jobs continue to flow, and CPU resources are used up a lot, we also hope that long jobs can be treated fairly.
Or, if long work becomes interactive work over a period of time, we should treat it more fairly. So we need to increase the priority in time, so there is rule three.
Rule 3: After an agreed period of time, all work will be moved to the highest priority queue.
Of course, adding the time period S leads to obvious questions: how should the value of S be set? The respected system researcher John Ousterhout once referred to this value as the "voo-doo constant" because it seemed to require some dark magic to set it correctly. If S is set too high, long jobs will be hungry; if it is set too low, interactive jobs will not get a proper CPU time ratio.
Implementation details
Many details of MLFQ are not given, for example:
- Number of queues
- Time slice length of each queue
- The priority interval for all groups
There is no optimal solution to these details. There are many specific implementations based on MLFQ ideas, each with its own characteristics.
Implementation details in the assignment
Should I directly preempt the CPU when the work I/O is over?
Whether to preempt has almost no effect on the average turnover period (but may change the turnover period), and has a certain impact on the average response period.
Because, when interactive work continues to occupy the CPU, the work arriving later will be difficult to execute.
Proportional share
Brief introduction
Proportional-share or fair-share
The goal is not to optimize turnaround time and response time, but to ensure that each job gets a given percentage of CPU time.
Lottery scheduling
Lottery scheduling is an implementation of the proportional share strategy. The basic idea is to decide which process to switch to next through a lottery.
Each process holds a certain number of tickets ( translated as a lottery in the book, I don't think it is accurate), and the share of the process is determined by the proportion of the tickets held by each process in all the tickets. At the end of each time slice, the scheduler uses random numbers to determine which process to run next.
The CPU resources occupied by each process converge to the share held by it with probability.
Lottery mechanism
-
Lottery currency (ticket currency)
The user holds a certain amount of currency, and the currency can be allocated to the processes under the user. The operating system will convert the currency held by the process into coupons according to the proportion of each user's currency.
-
Lottery transfer (ticket transfer)
One process can temporarily hand over its own coupons to another process to increase its share.
-
Lottery inflation (ticket inflation)
In an environment of mutual trust between processes, a process can temporarily increase or decrease the number of coupons it holds.
How to determine the share
The purpose of this strategy is not to solve the problem of distribution, the distribution of shares can be artificially stipulated.
For example, in supercomputing, it is reasonable to allocate a fixed CPU resource to a certain user.
achieve
lottery:
// counter: used to track if we’ve found the winner yet
int counter = 0;
// winner: use some call to a random number generator to
// get a value, between 0 and the total # of tickets
int winner = getrandom(0, totaltickets);
// current: use this to walk through the list of jobs
node_t *current = head;
while (current) {
counter = counter + current->tickets;
if (counter > winner)
break; // found the winner
current = current->next;
}
// ’current’ is the winner: schedule it...
In addition, when the running time is not very long, the randomness of the lottery seems not necessarily fair.
So there is a scheduling algorithm that guarantees fairness- step scheduling .
Stride scheduling
Basic idea: Calculate the step length according to the coupons held by each process. For example, the step lengths of the two processes with the number of coupons 1 and 2 are 2 and 1, respectively. Each time a process gets CPU resources for a time slice, its stroke value accumulates one step. As long as it is ensured that the stroke value of each scheduled process should not be greater than that of other processes, then this scheduling method is fair.
The book says that if a process is reached halfway, the process's stroke value is not easy to determine, so this method is not easy to implement.
I think we can achieve this:
Because the stroke value of all processes is always the same periodically. When it is consistent, the stroke value is all cleared, and then the process that arrived halfway is added and the stroke value is set to zero, and then the proportional share and step value are recalculated.
The problem with my method is that the operation of clearing all stroke values has considerable overhead.
To put it another way, when it is consistent, add the process that arrived midway, and set the stroke value to be the same as the current stroke value, and then clear it when the memory space used to save the stroke value is about to overflow.