© 2008 Wayne Wolf Overheads for Computers as Components 2 nd ed. Processes and operating systems zInterprocess communication. zOperating system performance. zPower management.

© 2008 Wayne Wolf Overheads for Computers as Components 2 nd ed. Interprocess communication zOS provides interprocess communication mechanisms: yvarious efficiencies; ycommunication power.

© 2008 Wayne Wolf Overheads for Computers as Components 2 nd ed. Interprocess communication zInterprocess communication (IPC): OS provides mechanisms so that processes can pass data. zTwo types of semantics: yblocking: sending process waits for response; ynon-blocking: sending process continues.

© 2008 Wayne Wolf Overheads for Computers as Components 2 nd ed. IPC styles zShared memory: yprocesses have some memory in common; ymust cooperate to avoid destroying/missing messages. zMessage passing: yprocesses send messages along a communication channel---no common address space.

© 2008 Wayne Wolf Overheads for Computers as Components 2 nd ed. Shared memory zShared memory on a bus: CPU 1CPU 2 memory

© 2008 Wayne Wolf Overheads for Computers as Components 2 nd ed. Race condition in shared memory zProblem when two CPUs try to write the same location: yCPU 1 reads flag and sees 0. yCPU 2 reads flag and sees 0. yCPU 1 sets flag to one and writes location. yCPU 2 sets flag to one and overwrites location.

© 2008 Wayne Wolf Overheads for Computers as Components 2 nd ed. Atomic test-and-set zProblem can be solved with an atomic test-and-set: ysingle bus operation reads memory location, tests it, writes it. zARM test-and-set provided by SWP: ADR r0,SEMAPHORE LDR r1,#1 GETFLAG SWP r1,r1,[r0] BNZ GETFLAG

© 2008 Wayne Wolf Overheads for Computers as Components 2 nd ed. Critical regions zCritical region: section of code that cannot be interrupted by another process. zExamples: ywriting shared memory; yaccessing I/O device.

© 2008 Wayne Wolf Overheads for Computers as Components 2 nd ed. Semaphores zSemaphore: OS primitive for controlling access to critical regions. zProtocol: yGet access to semaphore with P(). yPerform critical region operations. yRelease semaphore with V().

© 2008 Wayne Wolf Overheads for Computers as Components Message passing zMessage passing on a network: CPU 1CPU 2 message

© 2008 Wayne Wolf Overheads for Computers as Components 2 nd ed. Process data dependencies zOne process may not be able to start until another finishes. zData dependencies defined in a task graph. zAll processes in one task run at the same rate. P1P2 P3 P4

© 2008 Wayne Wolf Overheads for Computers as Components 2 nd ed. Signals in UML zMore general than Unix signal---may carry arbitrary data: > aSig p : integer someClass sigbehavior() >

© 2008 Wayne Wolf Overheads for Computers as Components 2 nd ed. Evaluating RTOS performance zSimplifying assumptions: yContext switch costs no CPU time,. yWe know the exact execution time of processes. yWCET/BCET don’t depend on context switches.

Scheduling and context switch overhead ProcessExecution time deadline P135 P2310 © 2008 Wayne Wolf Overheads for Computers as Components 2 nd ed. With context switch overhead of 1, no feasible schedule. 2TP1 + TP2 = 2*(1+3)+(1_3)=11

© 2008 Wayne Wolf Overheads for Computers as Components 2 nd ed. Process execution time zProcess execution time is not constant. zExtra CPU time can be good. zExtra CPU time can also be bad: yNext process runs earlier, causing new preemption.

© 2008 Wayne Wolf 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.

Effects of scheduling on the cache ProcessWCETAvg. CPU time P186 P243 P343 © 2008 Wayne Wolf Overheads for Computers as Components 2 nd ed. Schedule 1 (LRU cache): Schedule 2 (half of cache reserved for P1):

© 2008 Wayne Wolf Overheads for Computers as Components 2 nd ed. 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.

© 2008 Wayne Wolf Overheads for Computers as Components 2 nd ed. 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.

© 2008 Wayne Wolf Overheads for Computers as Components 2 nd ed. 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.

© 2008 Wayne Wolf Overheads for Computers as Components 2 nd ed. 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.

© 2008 Wayne Wolf Overheads for Computers as Components 2 nd ed. Advanced Configuration and Power Interface zACPI: open standard for power management services. Hardware platform device drivers ACPI BIOS OS kernel applications power management

© 2008 Wayne Wolf Overheads for Computers as Components 2 nd ed. 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