CS322: CPU Scheduling


  1. We have seen that a major task of an operating system is to manage a collection of processes, and that (in some cases) a single process may be structured as a set of individual threads.

  2. Both of these situations raise the following issue: on a system with a single CPU (or on a multi-processor system with fewer CPU's than processes), how is CPU time divided among the different processes/threads that are competing to use it?

  3. The component of the operating system that addresses these issues is called the scheduler. As we shall see, scheduling is often handled on several levels, with CPU scheduling being the lowest level. So we will want to discuss scheduling in general and CPU scheduling in particular.

  4. The scheduler works in cooperation with the interrupt system we discussed in the last class.

  5. We will now proceed as follows:

Basic Scheduling concepts

  1. Terminology

  2. Scheduler goals: schedulers typically attempt to achieve some combination of the following goals. Note that, to some extent, these goals are contradictory - hence what is achieved must be a compromise:

  3. Types of schedulers: A multiprogrammed system may include as many as three types of scheduler:

Scheduling Algorithms

  1. As noted above, our primary focus is on algorithms for short term scheduling, though most will be applicable to long-term as well.

  2. Scheduling algorithms can be classified in two different ways:

  3. We have classified scheduling algorithms broadly as FCFS vs priority and non-preemptive vs preemptive. Within the former group, priority algorithms can be further classified on the basis of how priorities are assigned. We have already noted the distinction between externally assigned and internally assigned (computed) priorities. Another way to look at this distinction is that external priorities are generally static (i.e. they stay the same throughout the life of a job) while internal priorities are often dynamic (they are recomputed on the basis of the process's behavior.)

Time quantum selection

  1. We have noted that most multiprogramming operating systems use some form of timer interruption to keep a single process from hogging the CPU. A key design question is the length of the time quantum to be used.

  2. One textbook author suggests that one picture an operating system as having a dial on the front labeled "q" (for quantum). Suppose the dial on a timeshared system is initially set at 0.

  3. A good rule of thumb would seem to be that the majority of processes should be able to complete a CPU burst without timer interruption. (The text suggests around 80% as a rule of thumb. This might be higher in a highly-interactive situation, or lower in a situation where there is much heavy computation going on.) The the time quantum will generally be a fraction of a second - perhaps between .1 and .5 or so.

  4. It is also possible to relate time quantum to priority. A compute bound process that could benefit from a long time quantum might be given a much longer than usual quantum, but also a lower priority. This would mean that it gets CPU bursts less often, but gets longer bursts each time, resulting in the same overall average CPU use with less overhead. (See discussion of multi-level feedback queues below.)

Scheduling data structures

  1. We noted above that, in the case of a FCFS algorithm, the "queue" of processes waiting for the CPU is indeed a queue in the data structures sense. Such queues can be implemented by linking PCB's together using a special field reserved for that purpose, with each PCB pointing to its sucessor. Two external pointers - one to the front of the queue and one to the rear - complete the implementation. Adding a new process to the end of the queue, and dispatching a process from the front are both easy.

             _______        _______
    	| Front | ---> | PCB   |
             -------       |       |_____
            | Rear  | -     -------     /
             -------   |    _______    /
                       |   | PCB   |<--
                       |   |       |_____
                       |    -------     /
                       |    _______    /
                       --->| PCB   |<--
                           |   null|

  2. The injection of priority necessitates a more complicated - and potentially more costly - data structure. Remember that the short term scheduler, in particular, is executed very frequently. Thus, overhead time must be kept to a minimum.

  3. When the set of possible priorities is limited, another approach may be used: multi-level queues. A single queue is maintained for each priority level. When a job is inserted, it is added at the end of the queue for its priority level, since we assume that FCFS is used between jobs of equal priority. The dispatcher always selects the front job from the queue having the highest priority.

          Example:	Priority 3:     Job X   Job D    Job M
                    Priority 2:     Job Y   Job W
                    Priority 1:     Job L   Job Z

    Assuming that priority 3 is the highest, the dispatcher will select Job X next. If a job A with priority 2 becomes ready, it is inserted after Job W in the level 2 queue.

  4. Multi-level queues are the basis of an interesting scheme to handle the time quantum problem discussed above. The scheme is called multi-level feedback queues.

Analyzing scheduling schemes

  1. With so many choices to be made among scheduling, it is desireable to have some basis for choice. In general, two approaches can be taken: various schemes can be analyzed; or a general scheme can be built with parameters (such as time quanta values, priority increments for certain events etc.) that can be tuned on the field.

  2. Discussion of analytical schemes is beyond our purpose here. We note that they include methods like:

  3. System tuning is still an important component of achieving efficiency - in other realms as well as scheduling. Unfortunately, much of this is still trial and error; but an experienced system manager will tend to discover those techniques that work for him.

$Id: cpu_scheduling.html,v 1.1 1998/02/04 04:56:40 senning Exp $

These notes were written by Prof. R. Bjork of Gordon College. In January 1998 they were converted to HTML and lightly editited by J. Senning of Gordon College.