1. © 2000 Morgan Kaufman Overheads for Computers as Components Processes and operating systems zScheduling policies: yRMS; yEDF. zScheduling modeling assumptions. zInterprocess communication. zPower management.

2. © 2000 Morgan Kaufman Overheads for Computers as Components Metrics zHow do we evaluate a scheduling policy: yAbility to satisfy all deadlines. yCPU utilization---percentage of time devoted to useful work. yScheduling overhead---time required to make scheduling decision.

3. © 2000 Morgan Kaufman Overheads for Computers as Components Rate monotonic scheduling zRMS (Liu and Layland): widely-used, analyzable scheduling policy. zAnalysis is known as Rate Monotonic Analysis (RMA).

4. © 2000 Morgan Kaufman Overheads for Computers as Components RMA model zAll process run on single CPU. zZero context switch time. zNo data dependencies between processes. zProcess execution time is constant. zDeadline is at end of period. zHighest-priority ready process runs.

5. © 2000 Morgan Kaufman Overheads for Computers as Components Process parameters  T i is computation time of process i;  i is period of process i. period  i Pi computation time T i

6. © 2000 Morgan Kaufman Overheads for Computers as Components Rate-monotonic analysis zResponse time: time required to finish process. zCritical instant: scheduling state that gives worst response time. zCritical instant occurs when all higher- priority processes are ready to execute.

7. © 2000 Morgan Kaufman Overheads for Computers as Components Critical instant P4 P3 P2 P1 critical instant P1 P2 P3 interfering processes

8. © 2000 Morgan Kaufman Overheads for Computers as Components RMS priorities zOptimal (fixed) priority assignment: yshortest-period process gets highest priority; ypriority inversely proportional to period; ybreak ties arbitrarily. zNo fixed-priority scheme does better.

9. © 2000 Morgan Kaufman Overheads for Computers as Components RMS example time 0510 P2 period P1 period P1 P2 P1

10. © 2000 Morgan Kaufman Overheads for Computers as Components RMS CPU utilization zUtilization for n processes is   i T i /  i zAs number of tasks approaches infinity, maximum utilization approaches 69%.

11. © 2000 Morgan Kaufman Overheads for Computers as Components RMS CPU utilization, cont’d. zRMS cannot asymptotically guarantee use 100% of CPU, even with zero context switch overhead. zMust keep idle cycles available to handle worst-case scenario. zHowever, RMS guarantees all processes will always meet their deadlines.

12. © 2000 Morgan Kaufman Overheads for Computers as Components RMS implementation zEfficient implementation: yscan processes; ychoose highest-priority active process.

13. © 2000 Morgan Kaufman Overheads for Computers as Components Earliest-deadline-first scheduling zEDF: dynamic priority scheduling scheme. zProcess closest to its deadline has highest priority. zRequires recalculating processes at every timer interrupt.

14. © 2000 Morgan Kaufman Overheads for Computers as Components EDF example P2 P1

15. © 2000 Morgan Kaufman Overheads for Computers as Components EDF analysis zEDF can use 100% of CPU. zBut EDF may miss a deadline.

16. © 2000 Morgan Kaufman Overheads for Computers as Components EDF implementation zOn each timer interrupt: ycompute time to deadline; ychoose process closest to deadline. zGenerally considered too expensive to use in practice.

17. © 2000 Morgan Kaufman Overheads for Computers as Components Fixing scheduling problems zWhat if your set of processes is unschedulable? yChange deadlines in requirements. yReduce execution times of processes. yGet a faster CPU.

18. © 2000 Morgan Kaufman Overheads for Computers as Components Priority inversion zPriority inversion: low-priority process keeps high-priority process from running. zImproper use of system resources can cause scheduling problems: yLow-priority process grabs I/O device. yHigh-priority device needs I/O device, but can’t get it until low-priority process is done. zCan cause deadlock.

19. © 2000 Morgan Kaufman Overheads for Computers as Components Solving priority inversion zGive priorities to system resources. zHave process inherit the priority of a resource that it requests. yLow-priority process inherits priority of device if higher.

20. © 2000 Morgan Kaufman Overheads for Computers as Components Data dependencies zData dependencies allow us to improve utilization. yRestrict combination of processes that can run simultaneously. zP1 and P2 can’t run simultaneously. P1 P2

21. © 2000 Morgan Kaufman Overheads for Computers as Components Context-switching time zNon-zero context switch time can push limits of a tight schedule. zHard to calculate effects---depends on order of context switches. zIn practice, OS context switch overhead is small.

22. © 2000 Morgan Kaufman Overheads for Computers as Components What about interrupts? zInterrupts take time away from processes. zPerform minimum work possible in the interrupt handler. P1 OS P2 OS intr P3

23. © 2000 Morgan Kaufman Overheads for Computers as Components Device processing structure zInterrupt service routine (ISR) performs minimal I/O. yGet register values, put register values. zInterrupt service process/thread performs most of device function.

24. © 2000 Morgan Kaufman Overheads for Computers as Components POSIX scheduling policies zSCHED_FIFO: RMS zSCHED_RR: round-robin ywithin a priority level, processes are time- sliced in round-robin fashion zSCHED_OTHER: undefined scheduling policy used to mix non-real-time and real- time processes.

25. © 2000 Morgan Kaufman Overheads for Computers as Components Interprocess communication zOS provides interprocess communication mechanisms: yvarious efficiencies; ycommunication power.

26. © 2000 Morgan Kaufman Overheads for Computers as Components Signals zA Unix mechanism for simple communication between processes. zAnalogous to an interrupt---forces execution of a process at a given location. yBut a signal is caused by one process with a function call. zNo data---can only pass type of signal.

27. © 2000 Morgan Kaufman Overheads for Computers as Components POSIX signals zMust declare a signal handler for the process using sigaction(). zHandler is called when signal is received. zA signal can be sent with sigqueue(): sigqueue(destpid,SIGRTMAX-1,sval)

28. © 2000 Morgan Kaufman Overheads for Computers as Components POSIX signal types zSIGABRT: abort zSIGTERM: terminate process zSIGFPE: floating point exception zSIGILL: illegal instruction zSIGKILL: unavoidable process termination zSIGUSR1, SIGUSR2: user defined

29. © 2000 Morgan Kaufman Overheads for Computers as Components Signals in UML zMore general than Unix signal---may carry arbitrary data: > aSig p : integer someClass sigbehavior() >

30. © 2000 Morgan Kaufman Overheads for Computers as Components POSIX shared memory zPOSIX supports counting semaphores with _POSIX_SEMAPHORES option. ySemaphore with N resources will not block until N processes hold the semaphore. zSemaphores are given name: y/sem1 zP() is sem_wait(), V() is sem_post().

31. © 2000 Morgan Kaufman Overheads for Computers as Components POSIX message-based communication zUnix pipe supports messages between processes. zParent process uses pipe() to create a pipe. yPipe is created before child is created so that pipe ID can be passed to child.

32. © 2000 Morgan Kaufman Overheads for Computers as Components POSIX pipe example /* create the pipe */ if (pipe(pipe_ends) < 0) { perror(“pipe”); break; } /* create the process */ childid = fork(); if (childid == 0) { /* child reads from pipe_ends[1] */ childargs[0] = pipe_ends[1]; execv(“mychild”,childargs); perror(“execv”); exit(1); } else { /* parent writes to pipe_ends[0] */ … }

33. © 2000 Morgan Kaufman Overheads for Computers as Components Evaluating performance zMay want to test: ycontext switch time assumptions; yscheduling policy. zCan use OS simulator to exercise process set, trace system behavior.

34. © 2000 Morgan Kaufman Overheads for Computers as Components Processes and caches zProcesses can cause additional caching problems. yEven if individual processes are well- behaved, processes may interfere with each other. zWorst-case execution time with bad behavior is usually much worse than execution time with good cache behavior.

35. © 2000 Morgan Kaufman Overheads for Computers as Components Power optimization zPower management: determining how system resources are scheduled/used to control power consumption. zOS can manage for power just as it manages for time. zOS reduces power by shutting down units. yMay have partial shutdown modes.

36. © 2000 Morgan Kaufman Overheads for Computers as Components Power management and performance zPower management and performance are often at odds. zEntering power-down mode consumes yenergy, ytime. zLeaving power-down mode consumes yenergy, ytime.

37. © 2000 Morgan Kaufman Overheads for Computers as Components Simple power management policies zRequest-driven: power up once request is received. Adds delay to response. zPredictive shutdown: try to predict how long you have before next request. yMay start up in advance of request in anticipation of a new request. yIf you predict wrong, you will incur additional delay while starting up.

38. © 2000 Morgan Kaufman Overheads for Computers as Components Probabilistic shutdown zAssume service requests are probabilistic. zOptimize expected values: ypower consumption; yresponse time. zSimple probabilistic: shut down after time T on, turn back on after waiting for T off.

39. © 2000 Morgan Kaufman Overheads for Computers as Components Advanced Configuration and Power Interface zACPI: open standard for power management services. Hardware platform device drivers ACPI BIOS OS kernel applications power management

40. © 2000 Morgan Kaufman Overheads for Computers as Components ACPI global power states zG3: mechanical off zG2: soft off xS1: low wake-up latency with no loss of context xS2: low latency with loss of CPU/cache state xS3: low latency with loss of all state except memory xS4: lowest-power state with all devices off zG1: sleeping state zG0: working state