Download presentation
Presentation is loading. Please wait.
1
Processes and operating systems
Scheduling policies: RMS; EDF. Scheduling modeling assumptions. Interprocess communication. Power management. © 2000 Morgan Kaufman Overheads for Computers as Components
2
Overheads for Computers as Components
Metrics How do we evaluate a scheduling policy: Ability to satisfy all deadlines. CPU utilization---percentage of time devoted to useful work. Scheduling overhead---time required to make scheduling decision. © 2000 Morgan Kaufman Overheads for Computers as Components
3
Rate monotonic scheduling
RMS (Liu and Layland): widely-used, analyzable scheduling policy. Analysis is known as Rate Monotonic Analysis (RMA). © 2000 Morgan Kaufman Overheads for Computers as Components
4
Overheads for Computers as Components
RMA model All process run on single CPU. Zero context switch time. No data dependencies between processes. Process execution time is constant. Deadline is at end of period. Highest-priority ready process runs. © 2000 Morgan Kaufman Overheads for Computers as Components
5
Overheads for Computers as Components
Process parameters Ti is computation time of process i; ti is period of process i. period ti Pi computation time Ti © 2000 Morgan Kaufman Overheads for Computers as Components
6
Rate-monotonic analysis
Response time: time required to finish process. Critical instant: scheduling state that gives worst response time. Critical instant occurs when all higher-priority processes are ready to execute. © 2000 Morgan Kaufman Overheads for Computers as Components
7
Overheads for Computers as Components
Critical instant P1 P2 P3 interfering processes P1 P2 P3 critical instant P4 © 2000 Morgan Kaufman Overheads for Computers as Components
8
Overheads for Computers as Components
RMS priorities Optimal (fixed) priority assignment: shortest-period process gets highest priority; priority inversely proportional to period; break ties arbitrarily. No fixed-priority scheme does better. © 2000 Morgan Kaufman Overheads for Computers as Components
9
Overheads for Computers as Components
RMS example P2 period P2 P1 period P1 P1 P1 5 10 time © 2000 Morgan Kaufman Overheads for Computers as Components
10
Overheads for Computers as Components
RMS CPU utilization Utilization for n processes is S i Ti / ti As number of tasks approaches infinity, maximum utilization approaches 69%. © 2000 Morgan Kaufman Overheads for Computers as Components
11
RMS CPU utilization, cont’d.
RMS cannot asymptotically guarantee use 100% of CPU, even with zero context switch overhead. Must keep idle cycles available to handle worst-case scenario. However, RMS guarantees all processes will always meet their deadlines. © 2000 Morgan Kaufman Overheads for Computers as Components
12
Overheads for Computers as Components
RMS implementation Efficient implementation: scan processes; choose highest-priority active process. © 2000 Morgan Kaufman Overheads for Computers as Components
13
Earliest-deadline-first scheduling
EDF: dynamic priority scheduling scheme. Process closest to its deadline has highest priority. Requires recalculating processes at every timer interrupt. © 2000 Morgan Kaufman Overheads for Computers as Components
14
Overheads for Computers as Components
EDF example P1 P2 © 2000 Morgan Kaufman Overheads for Computers as Components
15
Overheads for Computers as Components
EDF analysis EDF can use 100% of CPU. But EDF may miss a deadline. © 2000 Morgan Kaufman Overheads for Computers as Components
16
Overheads for Computers as Components
EDF implementation On each timer interrupt: compute time to deadline; choose process closest to deadline. Generally considered too expensive to use in practice. © 2000 Morgan Kaufman Overheads for Computers as Components
17
Fixing scheduling problems
What if your set of processes is unschedulable? Change deadlines in requirements. Reduce execution times of processes. Get a faster CPU. © 2000 Morgan Kaufman Overheads for Computers as Components
18
Overheads for Computers as Components
Priority inversion Priority inversion: low-priority process keeps high-priority process from running. Improper use of system resources can cause scheduling problems: Low-priority process grabs I/O device. High-priority device needs I/O device, but can’t get it until low-priority process is done. Can cause deadlock. © 2000 Morgan Kaufman Overheads for Computers as Components
19
Solving priority inversion
Give priorities to system resources. Have process inherit the priority of a resource that it requests. Low-priority process inherits priority of device if higher. © 2000 Morgan Kaufman Overheads for Computers as Components
20
Overheads for Computers as Components
Data dependencies Data dependencies allow us to improve utilization. Restrict combination of processes that can run simultaneously. P1 and P2 can’t run simultaneously. P1 P2 © 2000 Morgan Kaufman Overheads for Computers as Components
21
Context-switching time
Non-zero context switch time can push limits of a tight schedule. Hard to calculate effects---depends on order of context switches. In practice, OS context switch overhead is small. © 2000 Morgan Kaufman Overheads for Computers as Components
22
Overheads for Computers as Components
What about interrupts? Interrupts take time away from processes. Perform minimum work possible in the interrupt handler. P1 OS P2 intr OS P3 © 2000 Morgan Kaufman Overheads for Computers as Components
23
Device processing structure
Interrupt service routine (ISR) performs minimal I/O. Get register values, put register values. Interrupt service process/thread performs most of device function. © 2000 Morgan Kaufman Overheads for Computers as Components
24
POSIX scheduling policies
SCHED_FIFO: RMS SCHED_RR: round-robin within a priority level, processes are time-sliced in round-robin fashion SCHED_OTHER: undefined scheduling policy used to mix non-real-time and real-time processes. © 2000 Morgan Kaufman Overheads for Computers as Components
25
Interprocess communication
OS provides interprocess communication mechanisms: various efficiencies; communication power. © 2000 Morgan Kaufman Overheads for Computers as Components
26
Overheads for Computers as Components
Signals A Unix mechanism for simple communication between processes. Analogous to an interrupt---forces execution of a process at a given location. But a signal is caused by one process with a function call. No data---can only pass type of signal. © 2000 Morgan Kaufman Overheads for Computers as Components
27
Overheads for Computers as Components
POSIX signals Must declare a signal handler for the process using sigaction(). Handler is called when signal is received. A signal can be sent with sigqueue(): sigqueue(destpid,SIGRTMAX-1,sval) © 2000 Morgan Kaufman Overheads for Computers as Components
28
Overheads for Computers as Components
POSIX signal types SIGABRT: abort SIGTERM: terminate process SIGFPE: floating point exception SIGILL: illegal instruction SIGKILL: unavoidable process termination SIGUSR1, SIGUSR2: user defined © 2000 Morgan Kaufman Overheads for Computers as Components
29
Overheads for Computers as Components
Signals in UML More general than Unix signal---may carry arbitrary data: someClass <<signal>> aSig <<send>> sigbehavior() p : integer © 2000 Morgan Kaufman Overheads for Computers as Components
30
Overheads for Computers as Components
POSIX shared memory POSIX supports counting semaphores with _POSIX_SEMAPHORES option. Semaphore with N resources will not block until N processes hold the semaphore. Semaphores are given name: /sem1 P() is sem_wait(), V() is sem_post(). © 2000 Morgan Kaufman Overheads for Computers as Components
31
POSIX message-based communication
Unix pipe supports messages between processes. Parent process uses pipe() to create a pipe. Pipe is created before child is created so that pipe ID can be passed to child. © 2000 Morgan Kaufman Overheads for Computers as Components
32
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] */ … } © 2000 Morgan Kaufman Overheads for Computers as Components
33
Evaluating performance
May want to test: context switch time assumptions; scheduling policy. Can use OS simulator to exercise process set, trace system behavior. © 2000 Morgan Kaufman Overheads for Computers as Components
34
Overheads for Computers as Components
Processes and caches Processes can cause additional caching problems. Even if individual processes are well-behaved, processes may interfere with each other. Worst-case execution time with bad behavior is usually much worse than execution time with good cache behavior. © 2000 Morgan Kaufman Overheads for Computers as Components
35
Overheads for Computers as Components
Power optimization Power management: determining how system resources are scheduled/used to control power consumption. OS can manage for power just as it manages for time. OS reduces power by shutting down units. May have partial shutdown modes. © 2000 Morgan Kaufman Overheads for Computers as Components
36
Power management and performance
Power management and performance are often at odds. Entering power-down mode consumes energy, time. Leaving power-down mode consumes © 2000 Morgan Kaufman Overheads for Computers as Components
37
Simple power management policies
Request-driven: power up once request is received. Adds delay to response. Predictive shutdown: try to predict how long you have before next request. May start up in advance of request in anticipation of a new request. If you predict wrong, you will incur additional delay while starting up. © 2000 Morgan Kaufman Overheads for Computers as Components
38
Probabilistic shutdown
Assume service requests are probabilistic. Optimize expected values: power consumption; response time. Simple probabilistic: shut down after time Ton, turn back on after waiting for Toff. © 2000 Morgan Kaufman Overheads for Computers as Components
39
Advanced Configuration and Power Interface
ACPI: open standard for power management services. applications device drivers OS kernel power management ACPI BIOS Hardware platform © 2000 Morgan Kaufman Overheads for Computers as Components
40
ACPI global power states
G3: mechanical off G2: soft off S1: low wake-up latency with no loss of context S2: low latency with loss of CPU/cache state S3: low latency with loss of all state except memory S4: lowest-power state with all devices off G1: sleeping state G0: working state © 2000 Morgan Kaufman Overheads for Computers as Components
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.