Multiprocessor and Real Time Scheduling Bina Ramamurthy Chapter
Multiprocessor and Real. Time Scheduling Bina Ramamurthy Chapter 10 CSE 421 B. Ramamurthy 1
Introduction When a computer system contains more than a single processor, several new issues are introduced into the design of scheduling functions. We will examine these issues and the details of scheduling algorithms for tightly coupled multi-processor systems. B. Ramamurthy 2
Topics for discussion z Granularity of computation z Design issues y. Assignment of processes to processors y. Multiprogramming on individual processors y. Actual dispatching of a process z Real-time systems y. Characteristics y. Real-time scheduling y. Rate-monotonic scheduling (RMS) B. Ramamurthy 3
Granularity z The main purpose of having multiple processors is to realize__________? z Applications exhibit parallelism at various levels. There at least five categories of parallelism that differ in the degree of granularity. z Fine grain parallelism: Parallelism inherent in a single inst. stream. usually does not involve the OS but done at compilation stage. High data dependency ==> high frequency of synch. reqd. B. Ramamurthy 4
Granularity z Medium grain: Potential parallelism of an application can be implemented by multiple threads in a single process. High degree of coordination among the threads. Usually programmer specifies the parallelism in the design. z Coarse grain: Multiprocessing of concurrent processes in a multiprogramming environment : Example : Prj 2. z Very coarse grain: When the synchronization needed is not so frequent the processes can be distributed among network nodes to form a single computing environment. Example: CORBA standard for distributed system B. Ramamurthy 5
Design Issues z. Assignment of processes to processors. z. Use of multiprogramming on individual processors. z. Actual dispatching of a process. B. Ramamurthy 6
Process/processor Assignment z Master/slave assignment: Kernel functions always run on a particular processor. Other processors execute user processes. y. Advantage: Resource conflict resolution simplified since single processor has control. y. Problem: Failure of master processor? Master processor does the scheduling ==> bottleneck. z Peer assignment: OS can execute on any processor. Each processor does its own scheduling from the pool of available processes. This is similar to Solaris or NT symmetric multiprocessing (SMP). B. Ramamurthy 7
Multiprogramming at each processor z. Completion time and other applicationrelated performance metrics are much more important than processor utilization in multi-processor environment. z. For example, a multi-threaded application may require all its threads be assigned to different processors for good performance. z. Static or dynamic allocation of processes. B. Ramamurthy 8
Process dispatching z. After assignment, deciding who is selected from among the pool of waiting processes --- process dispatching. z. Single processor multiprogramming strategies may be counter-productive here. z. Priorities and process history may not be sufficient. B. Ramamurthy 9
Process scheduling z Single queue of processes or if multiple priority is used, multiple priority queues, all feeding into a common pool of processors. z Multi-server queuing model: multiplequeue/single queue , multiple server system. Study the system for 1, 2, and n processors. z Inference: Specific scheduling policy does not have much effect as the processor number increases. z Conclusion: Use FCFS with priority levels. B. Ramamurthy 10
Thread scheduling z An application can be implemented as a set of threads that cooperate and execute concurrently in the same address space. Criteria: When related threads run in parallel perf. improves. z Load sharing: pool of threads, pool of processors. z Gang scheduling: Bunch of related threads scheduled together. z Dedicated processor assignment: Each program gets as many processors as there are parallel threads. z Dynamic scheduling: More like demand scheduling. B. Ramamurthy 11
Real-time systems z Real-time computing is an important emerging discipline in CS and CE. z Control of lab experiments, robotics, process control, telecommunication etc. z It is a type of computing where correctness of the computation depends not only on the logical results but also on the time at which the results are produced. z Hard real-time systems: Must meet deadline. Ex: Space shuttle rendezvous with other space station. z Soft real-time system: Deadlines are there but not mandatory. Results are. B. Ramamurthy discarded if the deadline is not 12
Characteristics of Real. Time (RT) systems z. Determinism z. Responsiveness z. User control z. Reliability z. Fail-soft operation B. Ramamurthy 13
Deterministic Response z External event and timings dictate the request of service. z OS’s response depends on the speed at which it can respond to interrupts and on whether the system has sufficient capacity to handle requests. z Determinism is concerned with how long the OS delays before acknowledging an interrupt. z In non-RT this delay may be in the order of 10’s and 100’s of millisecs, whereas in an RT it may have an upper-bound of few microsec to 1 millisec. B. Ramamurthy 14
RT. . Responsiveness z Responsiveness is the time for servicing the interrupt once it has been acknowledged. z Comprises: y. Time to transfer control, (and context switch) and execute the ISR y. Time to handle nested interrupts, the interrupts that should be serviced when executing this ISR. Higher priority Interrupts. z response time = F(responsiveness, determinism) B. Ramamurthy 15
RT. . User Control z User control : User has a much broader control in RT-OS than in regular OS. z Priority z Hard or soft deadlines z Deadlines z Memory Managemenmt: paging or swapping z Name the processes to be resident in memory z Scheduling policies B. Ramamurthy 16
RT. . Reliability z Reliability: A processor failure in a non-RT may result in reduced level of service. But in an RT it may be catastrophic : life and death, financial loss, equipment damage. z Fail-soft operation: Ability of the system to fail in such a way preserve as much capability and data as possible. z In the event of a failure, immediate detection and correction is important. z Notify user processes to rollback. z Apply compensation. B. Ramamurthy 17
Requirements of RT z. Fast context switch z. Minimal functionality (small size) z. Ability to respond to interrupts quickly (Special interrupts handlers) z. Multitasking with signals and alarms z. Special storage to accumulate data fast z. Preemptive scheduling B. Ramamurthy 18
Requirements of RT (contd. ) z. Priority levels z. Minimizing interrupt disables z. Short-term scheduler (“omni-potent”) z. Time monitor z. Goal: Complete all hard real-time tasks by dead-line. Complete as many soft realtime tasks as possible by their deadline. B. Ramamurthy 19
Preemption and short-term scheduling z. Fig. 10. 4 B. Ramamurthy 20
RT scheduling z. Static table-driven approach y. For periodic tasks. y. Input for analysis consists of : periodic arrival time, execution time, ending time, priorities. y. Inflexible to dynamic changes. y. General policy: earliest deadline first. B. Ramamurthy 21
RT scheduling z. Static priority-driven preemptive scheduling y. For use with non-RT systems: Priority based preemptive scheduling. y. Priority assignment based on real-time constraints. y. Example: Rate monotonic algorithm B. Ramamurthy 22
RT scheduling z Dynamic planning-based scheduling y. After the task arrives before execution begins, a schedule is prepared that includes the new as well as the existing tasks. y. If the new one can go without affecting the existing schedules than nothing is revised. y. Else schedules are revised to accommodate the new task. y. Remember that sometimes new tasks may be rejected if deadlines cannot be met. B. Ramamurthy 23
RT scheduling z. Dynamic best-effort scheduling: yused in most commercial RTs of today ytasks are aperiodic, no static scheduling is possible ysome short-term scheduling such as shortest deadline first is used. y. Until the task completes we do not know whether it has met the deadline. B. Ramamurthy 24
Deadline scheduling z. Characteristics considered y. Aperiodic tasks y. Ready time y. Starting deadline y. Completion deadline y. Processing time y. Resource requirements y. Priority B. Ramamurthy 25
Scheduling tasks with completion deadline z. Fig. 10. 5, Table 10. 2 B. Ramamurthy 26
Scheduling tasks with starting deadline z. Fig. 10. 6, Table 10. 3 B. Ramamurthy 27
Rate Monotonic Scheduling z. Fig. 10. 7, Fig. 10. 8, Table 10. 4 B. Ramamurthy 28
Summary z. We studied issues and algorithms in z. Multi-processor scheduling z. Thread scheduling z. Real-time scheduling B. Ramamurthy 29
- Slides: 29