Body

CPU Scheduling

Processes alternate between using the CPU (called a CPU burst) and doing I/O.

Two categories of processes:

I/O bound processes - short CPU bursts e.g., iteractive, file processing
CPU bound processes - scientific calculation processes

Generally we want to favor I/O bound processes to get them doing I/O while the CPU bound processes use the CPU. A good scheduler seeks a balance between these conflicting goals:

Fairness - each process gets fair share of the CPU
Efficiency - keep the CPU and I/O devices as busy as possible
Response time - minimize response time for interactive users
Turnaround time - minimize time batch users must wait for output
Throughput - maximize the number of processes/jobs to complete per time

Timer can by used by the OS to periodically regain control of the CPU. Preemptive scheduling - stopping a runnable process and running another; used by most OSs In nonpreemptive scheduling a running process must "voluntarily" reliquish the CPU by terminating or doing I/O. Priority scheduling algorithms - each process has a priority and the highest priority process runs

Priorities might be dynamic or static, but usually there is some aging scheme to prevent starvation.

Process Priority could be based on:

External priority - system processes have higher priority, then faculty processes, then student processes
Internal criteria

resource usage - CPU time and memory space used (might be static)
CPU utilization - (dynamic) Favor I/O bound processes over CPU bound processes
e.g., set priority to 1/f, where f is the fraction of last time quantum used
resources held - e.g., if a process holds ¾ of main memory, then give it the CPU to get it out of the system

Possible scheduling algorithms

FCFS (First Come First Serve) - strict FIFO queue that is nonpreemptive.

Round Robin - cycle between each process giving each a CPU time quantum (a fixed amount of time); especially good for interactive or time-sharing processes

Quantum size must be chosen carefully

too small, then too much CPU time wasted doing context switching
too large, then response time too slow

Shortest Job First (SJF) - give CPU to process those next CPU burst is the shortest

Optimal w.r.t. the average waiting time of a process, i.e., it's useful to improve turnaround time of batch jobs or response-time of interactive jobs

Problem: we don't know how long a process' next CPU burst will be, but we can predict it from previous CPU bursts. One approach is to exponentially average previous CPU bursts as

Estimate first burst as t₁ (maybe use the system average)

Measure first CPU burst t₁

Prediction for second CPU burst: t₂ = at₁ + (1 - a)t₁, where 0 < a < 1

Measure second CPU burst t₂

Prediction for third CPU burst: t₃ = at₂ + (1 - a)t₂

...

Prediction for (n+1)^st CPU burst: t_n₊₁ = at_n + (1 - a)t_n,

Recall that t_n was recursively based on previous measured CPU bursts:

t_n₊₁ = at_n + (1 - a)t_n

= a(at_n-1 + (1 - a)t_n-1) + (1 - a)t_n = a²t_n-1 + a(1 - a)t_n-1 + (1 - a)t_n

= a²(at_n-2 + (1 - a)t_n-2) + a(1 - a)t_n-1 + (1 - a)t_n

= a³t_n-2 + a²(1 - a)t_n-2 + a(1 - a)t_n-1 + (1 - a)t_n

...

= (1 - a)[t_n + at_n-1 + a ²t_n-2 + a ³t_n-3 + ... + a ^n-1t₁] + a ⁿt₁

Since 0 < a < 1, larger powers of a place less weight on older burst times.

e.g., a = ½ and n = 3 (so n+1 = 4)

t₄ = ½ [t₃ + ½ t₂ + ¼ t₁] + 1/8 t₁ = ½ t₃ + ¼ t₂ + 1/8 t₁ + 1/8 t₁

Special cases:

If a = 0, t_n+1 = t_n (only use last CPU burst as a predictor).

If a = 1, t_n+1 = t₁ (don't use past history only system average).

If a = ½ , place ½ weight on last CPU burst and ½ weight on older runs.

(easy to implement when a = ½ or ¼ (or any power of 2)

Often multiple queues are used with different priority processes, e.g.,

Multilevel Feedback Queue - queues each have their own priority and scheduling algorithm, but there is some method to:

demote a process to a lower priority queue (usually CPU-burst time)
promote a process to a higher priority queue so it does not starve

Lottery scheduling - useful to allocate a resource (such as the CPU) with varying allocations

Idea: OS holds a lottery 50 times a second to see which process can use the CPU

The winning process uses the CPU for 20 msec. For example,

We'd expect that a process would get the CPU proportional to its fraction of all tickets.

Cooperating processes could exchange tickets to increase chance of running. For example, a server might be allocated zero tickets, but a client holding 30 tickets might transfer them to the server.

Multiple-Processor Scheduling

In a heterogeneous system, a process will only execute on compatible processor(s).

Several homogeneous processors allow load sharing via common ready queue.

Implementation options:

master-slave arrangement: a master processor delegates work to slave processors
distributed scheduling: each processor removes (/adds) next process from a common ready queue.

Evaluating New Scheduling Algorithms