CS703 – Advanced Operating Systems By Mr. Farhan Zaidi

Lecture No. 17

Some problems with multilevel queue concept Can’t low priority threads starve? Ad hoc: when skipped over, increase priority What about when past doesn’t predict future? e.g., CPU bound switches to I/O bound Want past predictions to “age” and count less towards current view of the world.

Summary + simple - short jobs can get stuck behind long ones; poor I/O FIFO: + simple - short jobs can get stuck behind long ones; poor I/O RR: + better for short jobs - poor when jobs are the same length STCF: + optimal (ave. response time, ave. time-to-completion) - hard to predict the future - unfair Multi-level feedback: + approximate STCF - unfair to long running jobs

Some Unix scheduling problems How does the priority scheme scale with number of processes? How to give a process a given percentage of CPU? OS implementation problem: OS takes precedence over user process user process can create lots of kernel work: e.g., many network packets come in, OS has to process. When doing a read or write system call, ….

Linux Scheduling Builds on traditional UNIX multi-level feedback queue scheduler by adding two new scheduling classes. Linux scheduling classes: - SCHED_FIFO: FCFS real-time threads - SCHED_RR: round-robin real-time threads - SCHED_OTHER: Other non-real-time threads Multiple priorities may be used within a class Priorities in real-time classes are higher than non-real- time classes.

Linux Scheduling (2) Rules for SCHED_FIFO 1. The system will not interrupt a SCHED_FIFO thread except in the following cases: Another FIFO thread of higher priority becomes ready The executing FIFO thread blocks on I/O etc. The executing FIFO threads voluntarily gives up the CPU e.g. terminates or yields 2. When an executing FIFO thread is interrupted, it is placed in the queue associated with its priority

Linux Scheduling (3) SCHED_RR class is similar to SCHED_FIFO except that there is a time-slice associated with an RR thread. On expiry of the time slice, if the thread is still executing, it is pre-empted and another thread from either SCHED_FIFO or SCHED_RR is selected for execution. SCHED_OTHER class is managed by the traditional UNIX scheduling algorithms i.e. multi-level feedback queue.

Lottery scheduling: random simplicity Problem: this whole priority thing is really ad hoc. How to ensure that processes will be equally penalized under load? Lottery scheduling! Very simple idea: give each process some number of lottery tickets On each scheduling event, randomly pick ticket run winning process to give process P n% of CPU, give it (total tickets)* n% How to use? Approximate priority: low-priority, give few tickets, high-priority give many Approximate STCF: give short jobs more tickets, long jobs fewer. Key: If job has at least 1, will not starve

Grace under load change Add or delete jobs (and their tickets): affect all proportionally Example: give all jobs 1/n of cpu? 4 jobs, 1 ticket each each gets (on average) 25% of CPU. Delete one job: automatically adjusts to 33% of CPU! Easy priority donation: Donate tickets to process you’re waiting on. Its CPU% scales with tickets of all waiters. 1 1

Classifications of Multiprocessor Systems Loosely coupled or distributed multiprocessor, or cluster Each processor has its own memory and I/O channels Functionally specialized processors Such as I/O processor Controlled by a master processor Tightly coupled multiprocessing Processors share main memory Controlled by operating system

Granularity of parallelism Coarse and Very Coarse-Grained Parallelism Synchronization among processes at a very gross level (after > 2000 instructions on the average) Good for concurrent processes running on a multiprogrammed uniprocessor Can by supported on a multiprocessor with little change

Granularity of parallelism Medium grained parallelism Single application is a collection of threads Threads usually interact frequently Fine-Grained Parallelism Highly parallel applications Specialized and fragmented area