1

Chapter 5, CPU Scheduling

2

5.1 Basic Concepts

• Simple, non-preemptive scheduling means that a new process can be scheduled on the CPU only when the current job has begun waiting, for I/O, for example

• The goal of multi-programming is to maximize the utilization of the CPU as a system resource by having a process running on it at all times

3

• The CPU-I/O Burst Cycle• A CPU burst refers to the period of time when a

given process occupies the CPU before making an I/O request or taking some other action which causes it to wait

• CPU bursts are of varying length and can be plotted in a distribution by length

• Overall system activity can also be plotted as a distribution of CPU and other activity bursts by processes

4

• The distribution of CPU burst lengths tends to be exponential or hyperexponential

5

6

• The CPU scheduler = the short term scheduler• (Under non-preemptive scheduling) when the

processor becomes idle, a new process has to be picked and allocated the CPU

• Note that the ready queue doesn’t have to be FIFO (although that is a simple, initial assumption)

• It does tend to be some sort of linked data structure with a queuing discipline which implements the scheduling algorithm

7

• Preemptive scheduling• Scheduling decisions can be made at these points:

1. A process goes from the run state to the wait state (e.g., I/O wait, wait for a child process to terminate)

2. A process goes from the run state to the ready state (e.g., as the result of an interrupt)

3. A process goes from the wait state to the ready state (e.g., I/O completes)

4. A process terminates

8

• Scheduling has to occur at points 1 and 4.• If it only occurs then, this is non-preemptive or

cooperative scheduling• If scheduling is also done at points 2 and 3, this

is preemptive scheduling• Notice that much of the discussion in the

previous chapters assumed preemptive scheduling—the use of interrupts, timers, etc., to trigger a context switch

9

• Historically, simple systems existed without timers, just like they existed without mode bits, for example

• It is possible to write a simple, non-preemptive operating system for multi-programming without multi-tasking

• Preemptive schedulers are more difficult to write and raise complex technical questions

10

• The problem with preemption comes from data sharing between processes

• If two concurrent processes share data, this can lead to inconsistent data, lost update, etc.

• Note that kernel data structures hold state for user processes. The user processes do not directly dictate what the kernel data structures contain, but by definition, the kernel loads the state of >1 user process

11

• This means that the kernel data structures themselves have the characteristic of data shared between processes

• As a consequence, in order to be correctly implemented, preemptive scheduling has to prevent inconsistent state in the kernel data structures

12

• This can be explained concretely by considering the movement of PCB’s from one queue to another

• If an interrupt occurs while one system process is moving a PCB, and the PCB has been removed form one queue, but not yet added to another, this is an error state

13

• Possible solutions to the problem• Only allow switching on I/O blocks. The idea is that

interrupts will be queued rather than instantaneous (a queuing mechanism will be needed)

• This means that processes will run to a point where they can be moved to an I/O queue and the next process will not be scheduled until that happens

• This solves the problem of preemptive scheduling—by backing off to non-preemptive scheduling

14

• Other solutions to the problem:• Only allow switching after a system call runs to

completion. In other words, make kernel processes uninterruptible. (This also assumes a queuing system for interrupts.) If the code that moves PCB’s around can’t be interrupted, inconsistent state can’t result.

• Make certain code segments in the O/S uninterruptible. This is the same idea, but with finer granularity. It increases concurrency because interrupts can occur in parts of kernel code.

15

• Note that this issue is related to the problem of real time operating systems

• If certain code blocks are not interruptible, you are not guaranteed a fixed, maximum response time to any particular system request or interrupt that you generate

• You may have to wait an indeterminate amount of time while the uninterruptible code finishes processing

• This violates the requirement for a hard real-time system

16

• The dispatcher = the module called by the short term scheduler which– Switches context– Switches to user mode– Jumps to the location in user code to run

• Speed is desirable. Dispatch latency refers to time lost in the switching process

17

• Scheduling criteria• There are various algorithms for scheduling• There are also various criteria for evaluating

them• Performance is always a trade-off• You can never maximize all of the criteria with

one scheduling algorithm

18

• Criteria• CPU utilization. The higher, the better. 40%-90% is

realistic• Throughput = processes completed / unit time• Turnaround time = total time for any single process to

complete• Waiting time = total time spent waiting in O/S queues• Response time = time between submission and first

visible sign of response to the request—important in interactive systems

19

• Depending on the criterion, you may want to:• Strive to attain an absolute maximum or

minimum (utilization, throughput)• Minimize or maximize the average

(turnaround, waiting)• Minimize or maximize the variance (for time-

sharing, minimize the variance, for example)

20

5.3 Scheduling Algorithms

• 5.3.1 First-Come, First-Served (FCFS)• 5.3.2 Shortest-Job-First (SJF)• 5.3.3 Priority• 5.3.4 Round Robin (RR)• 5.3.5 Multilevel Queue• 5.3.6 Multilevel Feedback Queue

21

• Reality involves a steady stream of many, many CPU bursts• Reality involves balancing a number of different

performance criteria or measures• Examples of the different scheduling algorithms will be

given below based on a very few processes and a limited number of bursts

• The examples will be illustrated using Gantt charts• The scheduling algorithms will be evaluated and

compared based on a simple measure of average waiting time

22

FCFS Scheduling

• The name, first-come, first-served, should be self-explanatory

• This is an older, simpler scheduling algorithm• It is non-preemptive• It is not suitable for interactive time sharing• It can be implemented with a simple FIFO

queue of PCB’s

23

• Consider the following scenario• Process Burst length• P1 24 ms.• P2 3 ms.• P3 3 ms.

24

Avg. wait time = (0 + 24 + 27) / 3 =17 ms.

25

• Compare with a different arrival order:• P2, P3, P1

26

Avg. wait time = (0 + 3 + 6) / 3 =3 ms.

27

• Additional comments on performance analysis• It is clear that average wait time varies greatly

depending on the arrival order of processes and their varying burst lengths

• As a consequence, it is also possible to conclude that for any given set of processes and burst lengths, arbitrary FCFS scheduling does not result in a minimal or optimal average wait time

28

• FCFS scheduling is subject to the convoy effect• There is the initial arrival order of process

bursts• After that, the processes enter the ready queue

after I/O waits, etc.• Let there be one CPU bound job (long CPU

burst)• Let there be many I/O bound jobs (short CPU

bursts)

29

• Scenario:• The CPU bound job holds the CPU• The other jobs finish their I/O waits and enter

the ready queue• Each of the other jobs is scheduled, FCFS, and

is quickly finished with the CPU due to an I/O request

• The CPU bound job then takes the CPU again

30

• CPU utilization may be high (good) under this scheme

• The CPU bound job is a hog• The I/O bound jobs spend a lot of their time waiting• Therefore, the average wait time will tend to be high• Recall that FCFS is not preemptive, so once the jobs

have entered, scheduling only occurs when a job voluntarily enters a wait state due to an I/O request or some other condition

31

SJF Scheduling

• The name, shortest-job-first, is not quite self-explanatory

• Various ideas involved deserve explanation• Recall that these thumbnail examples of scheduling

are based on bursts, not the overall job time• For scheduling purposes, it is the length of the next

burst that is important• There is no perfect way of predicting the length of

the next burst

32

• Implementing SJF in reality involves devising formulas for predicting the next burst length based on past performance

• SJF can be a non-preemptive algorithm. The assumption now is that all processes are available at time 0 for scheduling and the shortest is chosen

• A more descriptive name for the algorithm is “shortest next CPU burst” scheduling

33

• SJF can also be implemented as a preemptive algorithm. The assumption is that jobs enter the ready queue at different times. If a job with a shorter burst enters the queue when a job with a longer burst is running, the shorter job preempts the longer one

• Under the preemptive scenario a more descriptive name for the algorithm would be “shortest remaining time first” scheduling

34

Non-preemptive Example

• Consider the following scenario:• Process burst length• P1 6 ms.• P2 8 ms.• P3 7 ms.• P4 3 ms.

35

SJF order: P4, P1, P3, P2average wait time = (0 + 3 + 9 + 16) / 4 =

7 ms.

36

SJF average wait time is lower than the average wait time for FCFS scheduling of the same processes: FCFS

average wait time = (0 + 6 + 14 + 21) / 4 =10.25 ms.

37

• In theory, SJF is optimal for average wait time performance

• Always doing the shortest burst first minimizes the aggregate wait time for all processes

• This is only theoretical because burst length can’t be known

• In a batch system user estimates might be used• In an interactive system user estimates make no

sense

38

• Devising a formula for predicting burst time• The only basis for such a formula is past performance• What follows is the definition of an exponential average

function for this purpose• Let tn = actual, observed length of nth CPU burst for a given

process• Let Tn+1 = predicted value of next burst• Let a be given such that 0 <= a < 1• Then define Tn+1 as follows:

• Tn+1 = atn + (1 – a)Tn

39

• Explanation:• a is a weighting factor. How important is the

most recent actual performance vs. performance before that

• To get an idea of the function it serves, consider a = 0, a = ½, a = 1

40

• Tn appears in the formula. It is the previous prediction.

• It includes real past performance because• Tn = atn-1 + (1 – a)Tn-1

• Ultimately this expansion depends on the initial predicted value, T0

• Some arbitrary constant can be used, a system average can be used, etc.

41

• Expanding the formula• This illustrates how come it is known as an

exponential average• It gives a better feel for the role of the

components in the formula• Tn+1 = atn + (1-a)(atn-1 + (1-a)(…at0 + (1-a)T0)…)

• = atn + (1-a)atn-1 + (1-a)2atn-2 + … + (1-a)nat0 + (1-a)n+1T0

42

• The first term is:• atn

• The general term is:• (1 – a)jatn-j

• The last term is:• (1 – a)n+1T0

43

• In words• The most recent actual performance, tn, gets

weight a• All previous performances, ti, are multiplied by a

and by a factor of (1 – a)j, where the value of j is determined by how far back in time t occurred

• Since (1 – a) < 1, as you go back in time, the weight of a given term on the current prediction is exponentially reduced

44

• The following graph illustrates the results of applying the formula with T0 = 10 and a = ½

• With a = ½, the exponential coefficients on the terms of the prediction are ½, (½)2, (½)3, …

• Note that the formula tends to produce a lagging, not a leading indicator

• In other words, as the actual values shift up or down, the prediction gradually approaches the new reality, whatever it might be

45

prediction in

dex 0

prediction in

dex 1

prediction in

dex 2

prediction in

dex 3

prediction in

dex 4

prediction in

dex 5

prediction in

dex 6

prediction in

dex 70

2

4

6

8

10

12

14

actual burst lengthpredicted burst

46

Preemptive SJF

• If a waiting job enters the ready queue with an estimated burst length shorter than the time remaining of the burst length of the currently running job, then the shorter job preempts the one on the CPU.

• This can be called “shortest remaining time first” scheduling.

• Unlike in the previous examples, the arrival time of a process now makes a difference

47

• Consider the following scenario:• Process arrival time burst length• P1 0 8 ms.• P2 1 4 ms.• P3 2 9 ms.• P4 3 5 ms.

48

Preemptive SJF average wait time =(0 + 9 + 0 + 15 + 2) / 4 =

6.5 ms.

49

Walking through the example

• P1 arrives at t = 0 and starts• P2 arrivess at t = 1– P2’s burst length = 4– P1’s remaining burst length = 8 – 1 = 7– P2 preempts

• P3 arrives at t = 2– P3’s burst length burst length = 9– P2’s remaining burst length = 4 – 1 = 3– P1’s remaining burst length = 7– No preemption

50

• P4 arrives at t = 3– P4’s burst length = 5– P3’s remaining burst length = 9– P2’s remaining burst length = 3 – 1 = 2– P1’s remaining burst length = 7– No preemption

• P2 runs to completion at t = 5• P4 is scheduled. It runs to completion at t = 10• P1 is rescheduled. It runs to completion at 17• P3 is scheduled. It runs to completion at 26

51

Calculating the wait times for the example

• P1 has 2 episodes– 1st, enters at t = 0, starts at t = 0, wait time = 0– 2nd, waits from t = 1 to t = 10, wait time = 10 – 1 = 9– Total P1 wait time = 0 + 9

• P2 has 1 episode– Enters at t = 1, starts at t = 1, wait time = 1 – 1 = 0

• P3 has 1 episode– Enters at t = 2, starts at t = 17, wait time = 17 – 2 = 15

• P4 has 1 episode– Enters at t = 3, starts at t = 5, wait time = 5 – 3 = 2

• Total wait time = 0 + 9 + 0 + 15 + 2 = 26• Average wait time = 26 / 4 = 6.5

52

The same processes under non-preemptive SJF

53

• P1 wait = 0 – 0 = 0• P2 wait = 8 – 1 = 7• P3 wait = 17 – 2 = 15• P4 wait = 12 – 3 = 9• Total wait time = 0 + 7 + 15 + 9 = 31• Average wait time = 31 / 4 = 7.75

54

Priority Scheduling

• A priority is assigned to each process• High priority processes are scheduled before low

priority ones• Processes of equal priority are handled in FCFS order• In the textbook a high priority process is given a low

number and a low priority process is given a high number, e.g., 0-7, 0-4095

• Note that SJF is a type of priority scheduling where the priority is inversely proportional to the predicted length of the next burst

55

Priority Example

• Consider the following scenario:• Process burst length priority• P1 10 ms. 3• P2 1 ms. 1• P3 2 ms. 4• P4 1 ms. 5• P5 5 ms. 2

56

Average wait time = (0 + 1 + 6 + 16 + 18) / 5 = 41 / 5 =8.2 ms.

57

• Internal priority setting• SJF is an example• Other criteria that have been used:– Time limits– Memory requirements– (I/O burst) / (CPU burst)

58

• External priority setting:– Importance of process– Type or amount of funding– Sponsoring department– politics

59

• Priority scheduling can be either preemptive or non-preemptive

• Priority scheduling can lead to indefinite blocking = process starvation

• Low priority jobs may be delayed until low load times• Low priority jobs might be lost (in system crashes, e.g.)

before they’re finished• Solution to starvation: aging. Raise a process’s priority

by n units for every m time units it’s been in the system

60

Round Robin Scheduling

• This is the time-sharing scheduling algorithm• It is FCFS with fixed time-slice preemption• The time slice, or time quantum, is in the range of 10ms.-100ms.• The ready queue is a circularly linked list• The scheduler goes around the list allocating 1 quantum per

process• A process may block (I/O, e.g.) before the quantum is over• When an unfinished process leaves the CPU, it is added to the

“tail” of the circularly linked list• The tail “moves”. It is the point behind the currently scheduled

process

61

62

• RR scheduling depends on a hardware timer• The tradeoff in RR scheduling is fairness in

dividing up the CPU as a shared resource• Vs. long average waiting times for all

processes contending for it• If this is interactive time-sharing, the waiting

for human I/O will far outweigh the waiting time for access to the CPU

63

RR Example

• Consider the following scenario:• Let the time slice be 4 ms.• Process burst length• P1 24 ms.• P2 3 ms.• P3 3 ms.

64

Average wait time = (0 + 6 + 4 + 7) / 3 = 17 / 3 = 5 2/3

65

• Wait time for P1 = 0 initially• Wait time for P1 = 10 – 4 = 6 when scheduled

again• Wait time for P2 = 4• Wait time for P3 = 7

66

• The performance of round robin depends on the length of the time slice

• If the length of the slice is > any single process burst, then RR = FCFS

• If the slice is short, then in theory a machine with n users behaves like n machines, each 1/nth as fast as the actual machine

• This is the ideal, which ignores the overhead from switching between jobs

67

• A simple measure to gauge overhead cost is: (context switch time) / (time slice length)

• In order for time sharing to be practical, this ratio has to be relatively small

• The size of the ratio is dependent on hardware speed and O/S code efficiency (speed)

• Note that even if the ratio is acceptable, the number of users determines 1/n. The actual system speed determines how small you can make a time slice (slices per unit time) and how many users you can practically support at one time

68

• Round robin scheduling conveniently illustrates other performance parameters besides average waiting time

• Consider overall average process turnaround time as a function of time slice size

• Smaller time slices mean more context switching overhead on a percentage basis

• They also mean longer delays as each process has to wait for multiple slices

69

• On the other hand, if time slices are long, scheduling can degenerate into FCFS

• FCFS doesn’t fairly allocate the CPU in a time sharing environment

• The rule of thumb for system design and tuning is that 80% of all process CPU bursts should finish within 1 time slice

• Empirically, this shares the CPU while still achieving reasonable performance

70

RR time slice size variations

• Consider the following scenario:• Process burst length• P1 6 ms.• P2 3 ms.• P3 1 ms.• P4 7 ms.

71

Average turnaround time = (14 + 7 + 8 + 17) / 4 = 46 / 4 = 11 ½

72

Average wait time = ((0 + 8) + 4 + 7 + (8 + 2)) / 4 = 29 / 4 = 7 ¼

73

• Average waiting time and average turnaround time ultimately measure the same thing

• Average turnaround time varies as the time slice size varies

• However, it doesn’t vary in a regular fashion• Depending on the relative length of process

bursts and time slice size, a larger slice may lead to slower turnaround

74

time slice size 1

time slice size 2

time slice size 3

time slice size 4

time slice size 5

time slice size 6

time slice size 7

0

2

4

6

8

10

12

14

average turnaround timeaverage waiting time

75

• Keep in mind that all of these examples are thumbnails

• They are designed to give some idea of what’s going on, but they are not realistic in size

• In real life design and tuning would be based on an analysis of a statistically significant mass (relatively large) of historical or ongoing data

76

Multi-level Queue Scheduling

• A simple example• Let interactive jobs be foreground jobs• Let batch jobs be background jobs• Let foreground and background be distinguished by

keeping the jobs in separate queues where the queues have separate queuing disciplines/scheduling algorithms

• For example, use RR scheduling for foreground jobs• Use FCFS for batch jobs

77

• The follow-up question becomes, how do you coordinate scheduling between the two queues?

• One possibility: Fixed priority preemptive scheduling. Batch jobs only run if the interactive queue is empty

• Another possibility: Time slicing. For example, the interactive queue is given 80% of the time slices and the batch queue is given 20%

78

• Let different classes of jobs be permanently assigned to different queues

• Let the queues have priorities relative to each other

• Let each queue implement its own scheduling algorithm for the processes in it, which are of equal priority

79

An Example

80

• The coordination between queues would be similar to the interactive/batch example

• Fixed priority preemptive scheduling would mean that any time a job entered a queue of a higher priority, any currently running job would have to step aside

• Lower priority jobs could only run if all higher priority queues were empty

• You could time slice between the queues, giving a certain percent of CPU time to each one

81

Multi-level Feedback Queue Scheduling

• This introduces the possibility that processes move between queues

• This may be based on characteristics such as CPU or I/O usage or time spent in system

• In general, CPU greedy processes can be moved to a lower queue

• This gives interactive jobs and I/O bound jobs with shorter CPU bursts higher priority

• It can also handle ageing. If a job is in a lower priority queue too long, it can be moved to a higher one, preventing starvation

82

An Example

83

Queuing Discipline

• 1. The relative priority of the queues is fixed.– Jobs in queue 1 execute only if queue 0 is empty.– Jobs in queue 2 execute only if queue 1 is empty.

• 2. Every new job enters queue 0.– If its burst is <= 8, it stays there.– Otherwise, it’s moved to queue 1.

• 3. When a job in queue 1 is scheduled– If it has a burst length > 16, it’s preempted and

moved to queue 2.

84

• 4. Jobs can move back up to a different queue if their burst lengths are within the quantum of the higher priority queue.

• 5. Note that in a sense, this queuing scheme predicts future performance on the basis of the most recent burst length.

85

Defining Characteristics of a General Multi-Level Feedback Queue Scheduling System

• 1. The number of queues.• 2. The scheduling algorithm for each queue.• 3. The method used to determine when to

upgrade a process.• 4. The method used to determine when to

downgrade a process.• 5. The method used to determine which queue

a job will enter when it needs service (initially).

86

• Multi-level feedback queue systems are the most general and the most complex.

• The example given was simply that, an example.• In theory, such a system can be configured to

perform well for a particular hardware environment and job mix.

• In reality, there are no ways of setting the scheduling parameters except for experience, analysis, and trial and error.

87

5.4 Multiple Processor Scheduling

• Load sharing = the possibility of spreading work among >1 processor, assuming you can come up with a scheduling algorithm.

• Homogeneous systems = each processor is the same. Any process can be assigned to any processor in the system.

• Even in homogeneous systems, a process may be limited to a certain processor if a needed peripheral is attached to that processor

88

Approaches to Multiple Processor Scheduling

• Asymmetric multi-processing = master-slave architecture. The scheduling code runs on one processor only.

• Symmetric Multi-Processing (SMP) = each processor is self-scheduling.• There is still the question of whether the ready queue is local or

global.• To maximize concurrency, you need a global ready queue.• Maintaining a global ready queue requires cooperation (concurrency

control).• This is a difficult problem, so most systems maintain local ready

queues for each processor.• Most modern O/S’s support SMP: Windows, Solaris, Linux, Max OS X.

89

Processor Affinity

• This term refers to trying to keep the same job on the same processor.

• Moving jobs between processors is expensive.• Everything that might have been cached would

be lost unless explicitly recovered.• Soft affinity = not guaranteed to stay on the

same processor.• Hard affinity = guaranteed to stay on the same

processor.

90

Load Balancing

• This term refers to trying to keep all processors busy at all times.

• This is an issue if there are at least as many jobs as there are processors.

• If a global ready queue is implemented, load balancing would naturally be part of the algorithm.

91

• If a system only maintains local ready queues and there is not hard affinity, there are two approaches to moving jobs among processors:

• Push migration = a single system process regularly checks processor utilization and pushes processes from busy processors to idle ones.

• Pull migration = an idle processor reaches into the ready queue of a busy processor and extracts a process for itself.

92

• Both kinds of migration can be built into a system (Linux for example).

• By definition, migration and affinity are in opposition.

• There is a performance trade-off.• Some systems try to gauge imbalance in load

and only do migration if the imbalance rises above a certain threshold.

93

• Symmetric multi-threading = SMT• Definition: Provide multiple logical processors

rather than multiple physical processors.• This is known as hyperthreading on Intel chips.• At a hardware level:– Each logical processor has its own architecture state

(register values).– Each logical processor receives and handles its own

interrupts.– All hardware resources are shared.

94

• An O/S doesn’t have to be designed specifically for SMT.• SMT should be transparent—the machine “looks like”

an SMP machine.• A system may combine SMT and SMP—I.e., there would

be >1 logical processor on each of >1 physical processor.• If the O/S is system aware, it could be written to avoid

this scheduling case: >1 process on >1 local processor of 1 physical processor while another physical processor is idle.

95

Thread Scheduling

• This is essentially an expansion on ideas raised in the last chapter.

• The term “contention scope” refers to the level at which scheduling is occurring.

• Process Contention Scope (PCS) = the scheduling of threads on lightweight processes.

• In many-to-one or many-to-many schemes, threads of one or more user processes contend with each other to be scheduled.

• This is usually priority based, but not necessarily preemptive.

96

• System contention scope (SCS) = the scheduling of kernel level threads on the actual machine.

• In a one-to-one mapping scheme, these kernel threads happen to represent user threads belonging to one or more processes.

97

Operating System Examples

• In most previous chapters, the O/S example sections have been skipped because they involve needless detail.

• Concrete examples will be covered here for two reasons:– To give an idea of how complex real system are.– To show that if you know the basic principles, you

can tease apart the different pieces of an actual implementation.

98

Solaris Scheduling

• Solaris scheduling is based on four priority classes:– Real time– System– Time sharing– Interactive

99

• Practical points of Solaris scheduling:– High numbers = high priority, range of values: 0-

59– The four different priority classes are

implemented in three queues (3 and 4 are together).

– The distinction between 3 and 4 is that if a process requires the generation of windows, it is given a higher priority.

100

• There is an inverse relationship between priority and time slice size.– A small time slice = quick response for high

priority (interactive type) jobs.– A large time slice = good throughput for low

priority (CPU bound) jobs.

101

Solaris Scheduling Queue—Notice that Jobs Don’t Move Between Queues

102

Solaris Dispatch Table for Interactive and Time-sharing Threads

Starting Priority Allocated Time Quantum New Priority after Quantum Expiration

New Priority after Return from Sleep

0 200 0 50

5 200 0 50

10 160 0 51

15 160 5 51

20 120 10 52

25 120 15 52

30 80 20 53

35 80 25 54

40 40 30 55

45 40 35 56

50 40 40 58

55 40 45 58

59 20 49 59

103

Later Versions of Solaris Add these Details

• Fixed priority threads• Fair share priority threads• System processes don’t change priorities• Real-time processes have the absolutely highest

priorities• Each scheduling class has a set of priorities. These are

translated into global priorities and the schedule uses the global priorities to schedule

• Among threads of equal priority, the scheduler does RR scheduling

104

Windows XP Scheduling

• XP (kernel) thread scheduling is priority based preemptive

• This supports soft real-time applications• There are 32 priorities, 0-31• A high number = a high priority• There is a separate queue for each priority• Priority 0 is used for memory management

and will not come up further

105

• There is a relationship between priorities in the dispatcher and classes of jobs defined in the Win32 API

• There are 6 API classes divided into 2 groups according to the priorities they have

106

• Class: Real time. Priorities: 16-31• Variable (priority) classes:– High priority– Above normal priority– Normal priority– Below normal priority– Idle priority

• The priorities of these classes can vary from 1-15

107

• Within each class there are 7 additional subdivisions:– Time critical– Highest– Above normal– Below normal– Lowest– idle

108

• Each thread has a base priority• This corresponds to the relative priority it’s

given within its class• The default base value would be the “normal”

relative priority for the class• The distribution of values among classes and

relative priorities is shown in the following table

109

Columns = Priority Classes, Rows = Relative Priorities within ClassesThe ‘Normal’ row contains the base priorities for the classes.Real-time High Above

normalNormal Below

normalIdle priority

Time-critical

31 15 15 15 15 15

Highest 26 15 13 10 8 6

Above normal

25 14 11 9 7 5

Normal 24 13 10 8 6 4

Below normal

23 13 9 7 5 3

Lowest 22 11 8 6 4 2

Idle 16 1 1 1 1 1

110

• The scheduling algorithm dynamically changes a thread’s priority if it’s in the variable group

• If a thread’s time quantum expires, it’s priority is lowered, but not below its base priority

• When a thread is released from waiting, it’s priority is raised.

• How much it’s raised depends on what it was waiting for. For example:– Waiting for keyboard I/O—large raise– Waiting for disk I/O—smaller raise

111

• For an interactive process, if the user thread is given a raise, the windowing process it’s running in is also given a raise

• These policies favor interactive and I/O bound jobs and attempt to control threads that are CPU hogs

• XP has another feature that aids windowing performance

• If several process windows are on the screen and one is brought to the foreground, it’s time quantum is increased by a factor such as 3 so that it can get something done before being preempted.

112

Linux Scheduling

• Skip this• Two concrete examples are enough

113

Java Scheduling

• The JVM scheduling specification isn’t detailed• Thread scheduling is supposed to be priority

based• It does not have to be preemptive• Round-robin scheduling is not required, but a

given implementation may have it

114

• If a JVM implementation doesn’t have time-slicing or preemption, the programmer can try to devise cooperative multi-tasking in application code

• The relevant Java API method call is Thread.yield();

• This can be called in the run() method of a thread at the point where it is willing to give up the CPU to another thread

115

• Java Thread class name priorities:– Thread.MIN_PRIORITY (value = 1)– Thread.MAX_PRIORITY (value = 10)– Thread.NORM_PRIORITY (value = 5)

• A new thread is given the priority of the thread that created it

• The default priority is NORM• The system doesn’t change a thread’s priority

116

• The programmer can assign a thread a priority value in the range 1-10

• The relevant Java API method call is: Thread.currentThread().setPriority(value);

• This is done in the thread’s run() method• This specification isn’t foolproof though• Java thread priorities have to be mapped to O/S kernel thread

priorities• If the difference between Java priorities isn’t great enough, they

may be mapped to the same priority in the implementing system• The author gives Windows NT as an example where this can

happen

117

Algorithm Evaluation

• In general, algorithm selection is based on multiple criteria. For example:

• Maximiz CPU utilization under the constraint that maximum response time is <1 second

• Maximize throughput such that turnaround time, on average, is linearly proportional to total execution time

118

Deterministic Modeling

• This is a form of analytic evaluation• For a given set of jobs, with all parameters known, you

can determine performance under various scheduling scenarios

• This is OK for developing examples and exploring possibilities

• It’s not generally a practical way to pick a scheduling algorithm for a real system with an unknown mix of jobs

• The thumbnail analyses with Gantt charts are a simplified example of deterministic modeling

119

Queuing Models

• These are basically statistical models where the statistical assumptions are based on past observation of real systems

• The first distribution of interest• Arrival of jobs into the system• Typically Poisson

120

• All of the rest of the distributions tend to be exponential– CPU burst occurrence distribution– CPU burst length distribution– I/O burst occurrence distribution– I/O wait length distribution

121

• Given these distributions it is possible to calculate:

• Throughput• CPU utilization• Waiting time

122

A Simple Example of an Analysis Formula

• Let the following parameters be given:• N = number of processes in a queue• L = arrival rate of processes• W = average waiting time in queue• Then• N = L * W• This is known as Little’s formula• Given any two of the parameters, the third can be calculated• Note that the formula applies when the system is in a steady state—the

number of processes entering the queue = the number of processes leaving the queue

• Increase of decrease in the queue length occurs when the system is not in steady state

123

• Queuing models are not perfect• They are limited by the match or mismatch between the

chose distributions and actual behavior• They are simplifications because they aggregate behavior

and may overlook some factors• They rely on mathematical assumptions (they treat arrival,

service, and waiting as mathematically independent distributions, when for each process/burst these successive events are related)

• They are useful for getting ideas, but they do not perfectly match reality

124

Simulation Modeling

• Basic elements of a simulation:– A clock (discrete event simulation)– Data structures modeling state– Modules which model activity which changes state

125

• Simulation input:• Random number generation based on

statistical distributions for processes (again, mathematical simplification)

• Trace tapes. These are records of events in actual runs. They provide an excellent basis for comparing two algorithms

126

• Simulation models can generate statistics on all aspects of performance under the simulated workload

• Obtaining suitable input data and coding the simulation are not trivial tasks.

• Coding and O/S and living with the implementation choices it embodies are also not trivial

• Making the model may be worth the cost if it aids in developing the O/S

127

Implementation

• Implementation is the gold standard of algorithm evaluation and system testing

• You code an algorithm, install it in the O/S, and test it under real conditions

• Problems:– Coding cost– Installation cost– User reactions to modifications

128

User Reactions

• Changes in O/S code result from perceived shortcomings in performance

• Performance depends on the algorithm, the mix of jobs, and the behavior of jobs

• If the algorithm is changed, users will changed their code and behavior to adapt to the altered O/S runtime environment

• This can cause the same performance problem to recur, or a new problem to occur

129

• Examples:• If job priority is gauged by size (smaller jobs

given higher priority), programmers may break their applications into separate processes

• If job priority is gauged by frequency of I/O (I/O bound processes are given higher priority), programmers may introduce (needless) I/O into their applications

130

• Without resorting to subterfuge, a Java application programmer has some control over behavior in a single application by threading and using calls like yield() and setPriority()

• A large scale O/S will be tunable. The system administrator will be able to set scheduling algorithms and their parameters to meet the job mix at any given time

131

The End