Chapter 2 Processor Management

Chapter 2PROCESSOR MANAGEMENT

2.1 Introduction

• Processor management concerns with the management of physical processors, specially, the assignment of the processor to processes.

• The modules for the processor management are the job scheduler, the process scheduler and the traffic controller.

• The Job Scheduler It creates the processes, in a non multiprogramming

environment, and it would decide which process is to receive the processor.

• The Process Scheduler In the multiprogramming environment, it decides which of

the ready processes receive the processor, at what time, and for how long.

2.1.1 The Traffic Controller• It keeps track of the status of the processes. In most

systems it is necessary to synchronize between the processes and the jobs. The modules of the processor management usually perform this.

• Fig. (1.6) illustrates the domains of the job scheduling, the process scheduling, and the traffic controller. The job scheduling can be viewed as a macroscheduler, choosing which jobs will be run, while the process scheduler can be viewed as a microscheduler, assigning processor to the processes associated with scheduled jobs. The user views his job as a collection of tasks that he wants the computer system to perform for him. The user may divide his job into job steps (e.g. compile, load, execute, etc.) the system creates processes to do the computation of the job steps.

• So, the job scheduling is concerned with the management of jobs, and the process scheduling is concerned with the management of the processes.

• In the nonmultiprogramming system, no distinction is made between process and job scheduling, where only one job is allowed in the system at a time. In this simple system, the job scheduling chooses one job to run. Once the job is chosen, a process is created and assigned to the processor.

• For the multiprogramming system, the job scheduling chooses a small subset of the jobs submitted and lets them into the system therefore; the job scheduling creates processes for these jobs and assign the processes some resources.

• The process scheduling decides which of the processes within the subset will be assigned the processor at what time, and how long.

2.1.2 Job Scheduler

The job scheduler is the "super" manager, which must do the following:

• Keep track of the status of all jobs. It must note which jobs are trying to get some service (Hold State) and the status of all jobs being served (ready state, Running state, or Wait State).

• Choose the policy by which jobs will enter the system (i.e. go from Hold state to Ready State). This decision must be based on some characteristics as priority, resources required, or/and system balance.

• Allocate the necessary resources for the scheduled job by use of memory, device and processor management.

• Deallocate these resources when the job is terminated.

2.1.3 Process Scheduler• Once the job scheduler has moved a job from the Hold State to the

Ready State, it will create one or more processes for this job. In this time, the process scheduler decides which process gets the processor, when and for how long?

Therefore, the process scheduler should be satisfied the following:

• Keeping track of the status of the process (all processes are either running, ready, or wait). The module, which performs this function, is called the traffic controller.

• Deciding which process gets the processor and how long. The process scheduler performs this.

• Allocating of the processor to a process requires resting of the processor registers to correspond to the process correct state. The traffic controller performs this task.

• Deallocating of the processor, such that when the running process exceeds its current time, or must wait for an I/O operation. This requires that all processor state registers be saved to allow future reallocation. The traffic controller performs this task.

2.1.4 Structure of the Processor Management

In summary, the processor management operates on two levels:

• Assigning the processor to jobs (Macrolevel).• Assigning the processor to processes (Microlevel).

• Once a job is scheduled, the system must perform the functions of creating processes, Destroying processes, and Sending messages between processes.

• In the multiprogramming environment, the process scheduler may call by all modules of the system.

2.2 JOB Scheduler

• The functions of the job scheduler may be implemented simply. For example, in the Compatible Time Sharing System (CTSS), the job policy may consist of two levels:

• In the first level, admitting the first 30 users to Log-In to the system.

• In the second level, a priority algorithm allows a user with a high priority to force a low priority user to Log-Out (i.e., termination).

• Here we are concerned with the factors (policies) that go into scheduling of the job.

2.2.1 Policies

• The job scheduler must choose the jobs among the (Hold) jobs that will be made "ready" to run. In a small computing center, an external operator may do this function by choosing jobs arbitrarily; as choosing his friend's job, or short job.

• In the large system (e.g., OS/360), all submitted jobs may be first stored on a secondary storage. Then, the job scheduler examines all these submitted jobs, and according to specific policies, it will decide which jobs will have the system resources and hence will be run. The key concept here is that there are more jobs wish to run than those can be satisfied by the system resources. Therefore, scheduling must consider a policy issue, and this policy issue might be changed from time to time; because its goals are subjective and contradictory.

• One goal is concerned with running as many jobs as possible per day (Only run short jobs).

• Another goal is concerned with keeping the processor busy (Only computation intensive long jobs).

• Another goal is concerned with fairness to all jobs (what does "fair" mean).

The considerations must be satisfied to determine job scheduler policies are:

• Availability of special limited resources;– If the system gives preference, some users can "cheat". For example; if the

system run the job that requires a plotter, then some users will always request the plotter.

– If the system doesn't give preference, some users will suffer from extra delay.• Cost-higher rates for faster service.• System commitments-processor time and memory; the more the job wants,

the longer it waits.• Guaranteed service-setting a specific time limit.• System balancing-mixing I/O intensive and CPU intensive.• Completing the job at a specific time.

Once the job scheduler has selected a collection of jobs to run, the process scheduler attempts to handle the Microlevel (process) scheduling. On the other hands the job and process schedulers may interact; the process scheduler may choose to "postpone" a process and require that it goes through the Macrolevel (job) scheduling again in order to complete.

2.2.1.1 Scheduling Criteria

• Many criteria have been suggested for comparing CPU scheduling policies (algorithms). Criteria that are used include the following:

• CPU Utilization We want to keep CPU as busy as possible. CPU utilization may range from

0 to 100%. In real systems, it should range from 40% to 90%.• Throughput The number of jobs that are completed per time unit.• Turnaround Time The interval from the time of submission of a process to the time of

completion.• Waiting Time The sum of the periods spent waiting in the ready queue.• Response time The time from the submission to the first response.

2.2.2 Job Scheduling in Non-Multiprogramming Environment

In non-multiprogramming system, once a process has been assigned a processor, it does not release it until it is finished. In this section, the job scheduling using a policy to reduce average Turnaround Time will examined. The term of process and job may be used in interchangeably in the non-multiprogramming environment.

2.2.2.1 Job Scheduling Using First-In-First-Out(FIFO)

• Assume jobs arrive as indicated in Fig. (2.1). each arrived job will be arrangement as First-Come-First-Served, and the control will estimate the time would be taken to run each job. According to First-In-First-Out (FIFO) algorithm, the job will be run as depicted in Fig. (2.2):

Job NoArrival timeRun time

110.002.00 hrs

210.101.00hrs

310.25 0.25 hrs

Fig. (2.1) Sample Job Arrival time.

Job Scheduling Using First-In-First-Out(FIFO)

• The average Turnaround Time is computed as follows:

• Where:

Finish time

: Arrival time

AFT ii

n

1. TT

n

1ii

iF

iA

Fig. (2.2) Job Scheduler using FIFO.

Job No. Arrival time Start time Finish time Turnaround time

110.0010.0012.002.00 hrs

210.1012.0013.002.90 hrs

3 10.25 13.00 13.25 3.00 hrs

Average turnaround time = hrs7.90

63.23

90.7

2.2.2.2 Job Scheduler Using Shortest Job First

Fig. (2.3) illustrates a job scheduler algorithm that run the "Hold" job with the shortest time first. According to this algorithm, when job 1 arrives, it will be run. While job 1 is running, job 2 and job 3 arrive. After job 1 is finished, job 3 will be run because it has shortest estimated run time than job 2.

Fig. (2.3) Job Scheduler using shortest job first .

Job No. Arrival time Start time Finish time Turnaround time

110.0010.0012.002.00 hrs

210.1012.2513.253.15 hrs

3 10.25 12.00 12.25 2.00 hrs


38.23

15.7

Job Scheduler Using Shortest Job First

• This algorithm reduces the average turnaround time, but it does not fairer than that of FIFO algorithm; especially for job 2.

2.2.2.3 Job Scheduler Using Future Knowledge

In this algorithm, the turnaround time will be determined using future knowledge. According to this algorithm, at 10 AM if the system knows that there two shortest jobs will be arrived, it would not run job 1 and wait to the shortest jobs. Fig. (2.4) depicts the result of this algorithm.

Fig. (2.4) Job Scheduler using Future

Knowledge Job No. Arrival time Start time Finish time Turnaround time

110.0011.5013.503.50 hrs

210.1010.5011.501.40 hrs

3 10.25 10.25 10.50 0.25 hrs


72.13

15.5

Job Scheduler Using Future Knowledge

• By this algorithm, the average turnaround time is reduced, but the CPU was idle 0.25 hrs and probably made job 1 unhappy. Actually, many computation centers would prefer to leave the CPU idle during the busy afternoon rather than start up a low priority job.

The job scheduling algorithm has several problems:

• When a computation center uses this algorithm, the long jobs might be not run. This would cause that the center closes down immediately after some years.

• Future knowledge is rare.• Run time is usually estimated approximately.• Other resources must be considered, such as

memory requirement and I/O device, etc.

2.2.2.4 Measure of Scheduling Performance

In the above example, the turnaround time is used to measure the scheduling performance. In order to normalize the scheduling performance, another parameter must be defined, which is called the weighted turnaround time (W), where

T: the turnaround time.R: the actual run time.In the above examples (2.2, 2.3, and 2.4) the average turnaround times are:For example (2.2)

Average weighted turnaround time =

For examples (2.3) and (2.4) are 4.05 and 1.37 respectively.

Accordingly, we find that the scheduling policies that improved turnaround time is also improved waited turnaround time. This is not always true as we will see later.

9.1525.0

3

1

9.2

2

2

R

T

R

T

R

T

3

3

2

2

1

1

R

TW

3.53

9.15

2.2.3 Job Scheduling in Multiprogramming Environment

The function of the job scheduler in the multiprogramming system is how to select jobs to be run.

2.2.3.1 Job Scheduling in Multiprogramming with no I/O Overlap

When two jobs are in memory and they are being multiprogramming, but no I/O (i.e., all jobs use CPU only), the CPU spends time slice with each one.CPU HeadwayIt is the amount of CPU time spent on a job. If two jobs are being multiprogramming, each job's CPU headway will be equal to half of the clock time elapsed. Multiprogramming hurts performance based upon average turnaround time. To explain that, assume jobs arrive as indicated in Fig. (2.5).

Fig. (2.5) Job Arrival and Run times

Job NoArrival timeRun time

110.000.3 hrs

210.200.5 hrs

310.400.1 hrs

410.500.4 hrs

510.800.1 hrs

Fig. (2.6) shows the results of the FIFO scheduling algorithm for no multiprogramming

Job No.Arrival timeStart timeFinish timeTurn around time

Weighted turn around time

110.010.010.30.31.00

210.210.310.80.61.20

310.410.810.90.55.00

410.510.911.3 0.82.00

5 10.8 11.3 11.4 0.66.00

2.8 15.20

Average turnaround time, T=0.56

Average weighted turnaround time, W=3.04

FIFO scheduling algorithm for multiprogramming

In the multiprogramming, assume that a job may be started as it arrives. Job 1 arrived at 10 AM and it needed to run for 0.3 hours. After 0.2 hours, job 2 arrived so the processor will be time slices between them during the time segment 10.2 through 10.4. Thus even though job 1 had only 0.1 hours of execution left. The processor was servicing two jobs and it took 0.2 hours to complete job 1. the other times are verified as in Fig. (2.7a), Fig. (2.7b) shows the results of the FIFO algorithm with multiprogramming.

Fig. (2.7a) Graphical representation for FIFO –

with Multiprogramming

Fig. (2.7b) FIFO – with Multiprogramming

Job No.Arrival timeStart timeFinish timeTurn around time


110.010.010.40.41.33

210.210.311.351.152.3

310.410.810.650.252.5

410.510.911.40.92.25

5 10.8 11.3 11.1 0.33.0

3 11.38

Average turnaround time, T=0.6 hrs

Average weighted turnaround time, W=2.276 hrs

FIFO – with Multiprogramming

• As in Fig. (2.6) and Fig. (2.7b), the average turnaround time is 0.56 without multiprogramming and 0.6 with it. Is multiprogramming always bad? No.

• To answer this question, let us study the following example.

• Fig. (2.8a) and (2.8b) are for the scheduling with multiprogramming, while Fig. (2.9a) and (2.9b) are for scheduling without multiprogramming.

Fig. (2.8a) Graphical representation for FIFO–

with Multiprogramming

Fig. (2.8b) Example of Scheduling with

Multiprogramming Job No.Run timeStart timeFinish timeTurn around

timeWeighted turn

around time

13.010.014.04.01.3

20.510.011.51.53.0

30.2510.011.01.04.0

40.25 10.011.01.0 4.0

7.5 12.3



Fig. (2.9a) Graphical representation for FIFO– without Multiprogramming

Fig. (2.9b) Example of Scheduling without

Multiprogramming Job No.Run timeStart timeFinish timeTurn around

timeWeighted turn

around time

13.010.013.03.01.0

20.513.013.53.57.0

30.2513.513.753.7515.0

40.25 13.7514.04.0 16.0

14.25 39.0



2.2.3.2 Job Scheduling with Multiprogramming and I/O Overlap

The CPU can be used for other computations while the I/O is being handled by the I/O processor (channel). In the non-multiprogramming environment, the 25% of the CPU time would be wasted waiting I/O operations. However, in the multiprogramming environment the processor could be assigned to another computation during this waited time. In some time, it is possible for all jobs to be waiting for I/O at the same time, so the CPU may be still idle part of the time.

2.2.3.3 Job Scheduling with Memory

Requirements and no I/O Overlap

In addition to the CPU time, some jobs may need certain amount of memory. An analysis of the jobs using FIFO scheduling, which is depicted in Fig. (2.11). Assuming that available memory equals 100K and there is multiprogramming with no I/O overlap. Note, although job 3 arrived at 10.4, it could not start running till 11.1 because it needed 50K of course, which not available till 11.1.

Fig. (2.10) Sample Job requests for Scheduling

with Memory needed.

Job No .Arrival time Run time Memory needed

110.000.3 hrs10K

210.200.5 hrs60K

310.400.1 hrs50K

410.500.4 hrs30K

5 10.80 0.1 hrs 70K

Fig. (2.11a) Multiprogramming with Memory

Restriction.

Fig. (2.11b) Multiprogramming with Memory Restriction.

Job No.Run timeArrival timeFinish timeTurn around time


10.310.010.40.41.33

20.510.211.10.91.8

30.110.411.30.90.9

40.410.511.30.8 2.0

50.110.811.40.66.0

3.6 20.13



As in Fig. (2.11a) and (2.11b), due to the memory restriction, the average weighted time is increased.

2.2.3.4 Job Scheduling with Memory and

Tape Constraints and I/O Overlap

We consider that the jobs require also number of tape drives in addition to memory and CPU time. The effective of this requirement on the turnaround time can be studied with the following example (Fig. (2.12)). The job requirements are indicated in Fig. (2.13a) and (2.13b). assuming that the system has 100K memory and five tapes drives.

Fig. (2.13a) multiprogramming with

Memory and Tape Restriction.

Job No .Arrival time Run time Memory needed

Tape needed

110.000.3 hrs10K2

210.200.5 hrs60K3

310.400.1 hrs50K3

410.500.4 hrs30K2

5 10.80 0.1 hrs 70K 4

Fig. (2.13a) multiprogramming with

Memory and Tape Restriction.

Fig. (2.13b) Multiprogramming with

Memory and Tape Restriction. Job No.Run timeStart timeFinish timeTurn around

timeWeighted turn around time

10.310.410.44.01.33

20.510.211.10.91.8

30.110.411.30.90.9

40.410.511.30.8 2.0

50.110.811.40.66.0

3.6 20.13



Chapter 2 Processor Management

Documents