Lecture Notes for Operating Systems

================ Start Lecture #8 ================

Homework: 22, 23

Preemptive.
Perhaps it should be called ``snobbish RR''.
``Accepted processes'' run RR.
Accepted process have their priority increase at rate b>=0.
A new process starts at priority 0; its priority increases at rate a>=0.
A new process becomes an accepted process when its priority reaches that of an accepted process (or until there are no accepted processes).
Note that at any time all accepted processes have same priority.
If b>=a, get FCFS.
If b=0, get RR.
If a>b>0, it is interesting.

Sort jobs by total execution time needed and run the shortest first.

Nonpreemptive
First consider a static situation where all jobs are available in the beginning, we know how long each one takes to run, and we implement ``run-to-completion'' (i.e., we don't even switch to another process on I/O). In this situation, SJF has the shortest average waiting time
- Assume you have a schedule with a long job right before a short job.
- Consider swapping the two jobs.
- This decreases the wait for the short by the length of the long job and increases the wait of the long job by the length of the short job.
- This decreases the total waiting time for these two.
- Hence decreases the total waiting for all jobs and hence decreases the average waiting time as well.
- Hence, whenever a long job is right before a short job, we can swap them and decrease the average waiting time.
- Thus the lowest average waiting time occurs when there are no short jobs right before long jobs.
- This is SJF.
In the more realistic case where the scheduler switches to a new process when the currently running process blocks (say for I/O), we should call the policy shortest next-CPU-burst first.
The difficulty is predicting the future (i.e., knowing in advance the time required for the job or next-CPU-burst).
This is an example of priority scheduling.

Preemptive version of above

Permit a process that enters the ready list to preempt the running process if the time for the new process (or for its next burst) is less than the remaining time for the running process (or for its current burst).
It will never happen that a process in the ready list will require less time than the remaining time for the currently running process. Why?
Ans: When the process joined the ready list it would have started running if the current process had more time remaining. Since that didn't happen the current job had less time remaining and now it has even less.
Can starve processs that require a long burst.
- This is fixed by the standard technique.
- What is that technique?
  Ans: Priority aging.
Another example of priority scheduling.

Run the process that has been ``hurt'' the most.

For each process, let r = T/t; where T is the wall clock time this process has been in system and t is the running time of the process to date.
If r=5, that means the job has been running 1/5 of the time it has been in the system.
We call r the penalty ratio and run the process having the highest r value.
HPRN is normally defined to be non-preemptive (i.e., the system only checks r when a burst ends), but there is an preemptive analogue
- Do not worry about a process that just enters the system (its ratio is undefined)
- When putting process into the run state commpute the time at which it will no longer have the highest ratio and set a timer.
- When a process is moved into the ready state, compute its ratio and preempt if needed.
HRN stands for highest response ratio next and means the same thing.
This policy is another example of priority scheduling

Put different classes of processs in different queues

Processs do not move from one queue to another.
Can have different policies on the different queues.
For example, might have a background (batch) queue that is FCFS and one or more foreground queues that are RR.
Must also have a policy among the queues.
For example, might have two queues, foreground and background, and give the first absolute priority over the second
- Might apply aging to prevent background starvation.
- But might not, i.e., no guarantee of service for background processes. View a background process as a ``cycle soaker''.
- Might have 3 queues, foreground, background, cycle soaker

Many queues and processs move from queue to queue in an attempt to dynamically separate ``batch-like'' from interactive processs.

Run processs from the highest priority nonempty queue in a RR manner.
When a process uses its full quanta (looks a like batch process), move it to a lower priority queue.
When a process doesn't use a full quanta (looks like an interactive process), move it to a higher priority queue.
A long process with frequent (perhaps spurious) I/O will remain in the upper queues.
Might have the bottom queue FCFS.
Many variants
For example, might let process stay in top queue 1 quantum, next queue 2 quanta, next queue 4 quanta (i.e. return a process to the rear of the same queue it was in if the quantum expires).

Considerable theory has been developed.

Decisions made at a coarser time scale.

Called two-level scheduling by Tanenbaum.
Suspend (swap out) some process if memory is over-committed.
Criteria for choosing a victim.
- How long since previously suspended.
- How much CPU time used recently.
- How much memory does it use.
- External priority (pay more, get swapped out less).
We will discuss medium term scheduling again next chapter (memory management).

``Job scheduling''. Decide when to start jobs, i.e., do not necessarily start them when submitted.
Force user to log out and/or block logins if over-committed.
- CTSS (an early time sharing system at MIT) did this to insure decent interactive response time.
- Unix does this if out of processes (i.e., out of PTEs)
- ``LEM jobs during the day'' (Grumman).
Some supercomputer sites.