This is so because in most cases the process performs a system call or an external interrupt happens [4]. The clock interrupt therefore serves mainly as a backup.
And it also improves fairness
Finally, we note that even if processes do not engage in infinite loops, some are compute-bound while others are interactive or IO-bound. Without preemption,
CPU-bound processes may lock out the interactive processes for excessive periods, which is undesirable. Preempting them regularly allows interactive processes to get
a chance to run, at least once in a while. But if there are many compute-bound pro- cesses, this may not be enough. The solution is then to give the interactive processes
higher priorities.
3.3.4 Priority Scheduling
Interactive jobs can get priority based on past behavior
Round robin scheduling is oblivious — it does not take into account any information about previous behavior of the processes. All processes receive equal treatment.
However, the system can easily accumulate information about the processes, and prioritize
them. Interactive jobs, such as a text editor, typically interleave short bursts of CPU activity with IO operations to the terminal. In order to improve responsive-
ness, the system should give high priority to such jobs. This can be done by regarding the CPU burst as the unit of computing, and scheduling processes with short bursts
first this is a variant of SJF.
The question remains of how to estimate the duration of the next burst. One option is to assume it will be like the last one. Another is to use an average of all previous
bursts. Typically a weighted average is used, so recent activity has a greater influence on the estimate. For example, we can define the
n + 1st estimate as E
n +1
= 1
2 T
n
+ 1
4 T
n− 1
+ 1
8 T
n− 2
+ 1
16 T
n− 3
+ . . . where
E is the estimate, T is the duration of the burst, and as bursts become more distant they are given half the weight a simple generalization is to use another factor
≤ α ≤ 1 to set the relative weights. Exercise 58 Can this be computed without storing information about all the previous
bursts?
Multi-level feedback queues learn from past behavior
Multi-level feedback queues are a mechanism to differentiate among processes based on their past behavior. It is similar to the SJF-like policy described above, but simpler
72
and does not require the system to maintain a lot of historical information. In effect, the execution history of the process is encoded in the queue in which it resides, and it
passes from queue to queue as it accumulates CPU time or blocks on IO.
New processes and processes that have completed IO operations are placed in the first queue, where they have a high priority and receive a short quantum. If they do
not block or terminate within this quantum, they move to the next queue, where they have a lower priority so they wait longer, but then they get a longer quantum.
In this way, a series of queues is created: each additional queue holds jobs that have already run for a longer time, so they are expected to continue to run for a long
time. Their priority is reduced so that they will not interfere with other jobs that are assumed to be shorter, but when they do run they are given a longer quantum
to reduce the overhead of context switching. The scheduler always serves the lowest non-empty queue.
CPU
queue 0
queue 1 queue 2
queue 3 new jobs
quantum = 10 quantum = 20
quantum = 40 quantum = 80
terminated
In Unix, priority is set by CPU accounting
The Unix scheduler also prioritizes the ready processes based on CPU usage, and schedules the one with the highest priority which is the lowest numerical value.
The equation used to calculate user-level priorities is the following when running in kernel mode, the priority is fixed:
pri = cpu use + base + nice cpu use is recent CPU usage. This value is incremented for the running process on
every clock interrupt typically 100 times a second. Thus the priority of a process goes down as it runs. In order to adjust to changing conditions, and not to over-penalize
long running jobs, the
cpu use value is divided in two for all processes once a second 73
this is called exponential aging. Thus the priority of a process goes up as it waits in the ready queue.
runs process
runs process
CPU usage accounting
high priority low priority
exponential aging process waits in queue
time
base is the base priority for user processes, and distinguishes them from kernel priorities. A process that goes to sleep in a system call, e.g. when waiting for a disk
operation to complete, will have a higher priority. Thus when it wakes up it will have preference over all user-level processes. This will allow it to complete the system
call and release kernel resources. When it returns to user mode, its priority will be reduced again.
nice is an optional additional term that users may use to reduce the priority of their processes, in order to be nice to their colleagues.
Exercise 59 Does the Unix scheduler give preference to interactive jobs over CPU- bound jobs? If so, how?
Exercise 60 Can a Unix process suffer from starvation? The implementation of Unix scheduling is essentially similar to multilevel feed-
back queues, except that time quanta are not varied. As CPU accounting is only done at a rather coarse granularity, there are actually a relatively small number of possible
priority levels: in most systems this is 32, 64, or 128 if the range of possible account- ing values is larger, it is scaled to fit. The system maintains an array of pointers,
one for each priority level. When a process is preempted or blocks, it is linked to the pointer that matches its current priority. The scheduler always chooses the process
at the head of the topmost non-empty list for execution.
Exercise 61 Assuming that CPU usage is accounted at a rate of 100Hz that is, the us- age of the running process is incremented by 100 every 10ms, and that all accounts are
halved once a second, what is the maximal priority value that a process may achieve?
To read more: Unix scheduling is described in Bach [1, Sect. 8.1] system V and in McKusick [11, Sect. 4.4] 4.4BSD. The BSD formula is slightly more complicated.
74
3.3.5 Starvation, Stability, and Allocations
