Survey							
                            
		                
		                * Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Scheduling Operating Systems Spring 2004 OS Spring’04 Multiprogramming  Multiprogramming: having multiple jobs (processes) in the system Interleaved (time sliced) on a single CPU Concurrently executed on multiple CPUs Both of the above  Why multiprogramming? Responsiveness, utilization, concurrency  Why not? Overhead, complexity OS Spring’04 Responsiveness Job 1 arrives Job 2 arrives Job 3 arrives Job1 Job 1 terminates Job1 Job3 Job2 Job 2 Job 3 terminates terminates Job3 Job 1 terminates OS Spring’04 Job2 Job 3 terminates Job 2 terminates Utilization 1st I/O operation CPU I/O 2nd I/O ends operation idle CPU Job1 Disk idle idle Job2 Job1 3rd I/O operation idle idle Disk I/O ends idle idle Job1 idle idle Job2 OS Spring’04 Job2 Job1 idle Workload matters! ? Does it really matter? Yes, of course: If all jobs are CPU bound (I/O bound), multiprogramming does not help to improve utilization  A suitable job mix is created by a longterm scheduling Jobs are classified on-line to be CPU (I/O) bound according to the job’s history OS Spring’04 Concurrency  Concurrent programming Several process interact to work on the same problem  ls –l | more Simultaneous execution of related applications  Word + Excel + PowerPoint Background execution  Polling/receiving Email while working on smth else OS Spring’04 The cost of multiprogramming  Switching overhead Saving/restoring context wastes CPU cycles  Degrades performance Resource contention Cache misses  Complexity Synchronization, concurrency control, deadlock avoidance/prevention OS Spring’04 Short-Term Scheduling terminated running schedule wait for event preempt created ready blocked event done OS Spring’04 Short-Term scheduling  Process execution pattern consists of alternating CPU cycle and I/O wait  CPU burst – I/O burst – CPU burst – I/O burst...  Processes ready for execution are hold in a ready (run) queue  STS schedules process from the ready queue once CPU becomes idle OS Spring’04 Preemptive/non-preemptive  Four events in which the scheduler may decide to switch the CPU to a new process Running process terminates Running process blocks (e.g., for I/O) Non-ready process becomes ready (or starts) Clock interrupt  The latter two cause preemption  Advantages: Better time sharing, responsiveness Guard against endless loops  Disadvantages: Higher programming complexity  Example: Unix disables interrupts within kernel mode Disrupts real-time OS Spring’04 Metrics: Response time  Response time (turnaround time) is the average over the jobs’Tresp Job arrives/ becomes ready to run Starts running Job terminates/ blocks waiting for I/O Trun Twait Tresp Tresp= Twait + Trun OS Spring’04 Metrics  Wait time: average of Twait This parameter is under the system control  Throughput Number of complete process terminations within a time unit  Utilization Fraction of time CPU is utilized OS Spring’04 Off-line vs. On-line scheduling  Off-line algorithms Get all the information about all the jobs to schedule as their input Outputs the scheduling sequence Preemption is never needed  On-line algorithms Jobs arrive at unpredictable times Very little info is available in advance Preemption compensates for lack of knowledge OS Spring’04 First-Come-First-Serve (FCFS)  Schedules the jobs in the order in which they arrive Off-line FCFS schedules in the order the jobs appear in the input     Runs each job to completion Both on-line and off-line Simple, a base case for analysis Poor response time OS Spring’04 Shortest Job First (SJF)  Best response time Short Long job Long job Short  Inherently off-line All the jobs and their run-times must be available in advance OS Spring’04 Preemption  Preemption is the action of stopping a running job and scheduling another in its place  Context switch: Switching from one job to another OS Spring’04 Using preemption  On-line short-term scheduling algorithms Adapting to changing conditions  e.g., new jobs arrive Compensating for lack of knowledge  e.g., job run-time  Periodic preemption keeps system in control  Improves fairness Gives I/O bound processes chance to run OS Spring’04 Shortest Remaining Time first (SRT)  Job run-times are known  Job arrival times are not known  When a new job arrives: if its run-time is shorter than the remaining time of the currently executing job: preempt the currently executing job and schedule the newly arrived job else, continue the current job and insert the new job into a sorted queue  When a job terminates, select the job at the queue head for execution OS Spring’04 Round Robin (RR)  Both job arrival times and job run-times are not known  Run each job cyclically for a short time quantum Approximates CPU sharing Job 1 arrives Job 2 arrives Job 3 arrives Job 3 terminates Job1 2 1 2 3 1 2 3 1 2 3 1 OS Spring’04 Job 1 terminates Job2 Job 2 terminates Responsiveness Job 1 arrives Job 2 arrives Job 3 arrives Job1 Job 1 terminates Job1 Job3 Job2 Job 2 Job 3 terminates terminates Job3 Job 1 terminates OS Spring’04 Job2 Job 3 terminates Job 2 terminates Priority Scheduling  Example: prioritize processes according to their past CPU usage Equivalent to SJF with predicted next CPU burst time En1  Tn  (1   ) En , 0    1 1 1 1 1 1   : En1  Tn  Tn1  Tn2  Tn3   2 2 4 8 16  Tn is the duration of the n-th CPU burst  En+1 is the estimate of the next CPU burst OS Spring’04 Multilevel feedback queues new jobs quantum=10 quantum=20 quantum=40 FCFS OS Spring’04 terminated Multilevel feedback queues  Priorities are implicit in this scheme  Very flexible  Starvation is possible Short jobs keep arriving => long jobs get starved  Solutions: Let it be Aging OS Spring’04 Real-life examples  Solaris 2  Window 2000  Linux OS Spring’04