Rethinking OS Design

1. Rethinking OS Design Productivity applications Process control Personal (PDAs), Embedded Workload Services & API Internal Structure You are here Metrics Policies / Mechanisms Energy efficiency Hardware Resources Processor, Memory, Disks (?), Wireless & IR, Keyboard(?), Display(?), Mic & Speaker, Motors & Sensors, GPS, Camera, Batteries

2. Energy/Power-related APIs • OnNow and ACPI • Odyssey

3. ACPIAdvanced Computer Power Initiative Brought to you by Intel, Microsoft, and Toshiba and designed to enable OS Directed Power Management (OSPM). • Goal is to be able to move power management into software for more sophisticated policies • Abstract OS-HW interface

4. S4 S3 S2 S1 G1Sleep Power States G: global states apply to entire system and are visible to user D: states of individual devices S: sleeping states within the G1 state C: CPU states G3mech off wakeup G0-S0working Legacy G2-S5Soft off Dxmodem x DxHDD xDxcdrom x Cxcpu

5. Transmeta Crusoe ACPI Power States

6. Transmeta Crusoe Power

7. Applications OnNow WIN32 ext OS ACPI Spec HW OSDM: OnNow SetSystemPowerState • initiate sleep state, query apps(?) SetThreadExecutionState • specifies level of support needed (e.g. display required) WM_POWERBROADCAST • a message notifying of power state changes to which applications can respond SetWaitableTimer • ensure PC is awake at scheduled time RequestDeviceWakeup RequestWakeupLatency - to specify latency requirements GetSystemPowerStatus and GetDevicePowerState

8. Measuring Energy • Similar problems of relating timings to states (non-intrusively). • idle loop in [Endo] isn’t “idle” in power sense • Additionally, need power costs of states

9. PowerScope [Flinn] • Statistical sampling approach • Program counter/process (PC/PID) + correlated current readings. • Off-line analysis to generate profile • Causality • Goal is to assign energy costs to specific application events / program structure • Mapped down to procedure level • System-wide. Includes all processes, including kernel

10. Experimental SetupData Gathering Multimeter’sclock drivessampling at period of 1.6ms Takescurrentsample -> InterruptcausesPC/PID sample to be buffered ->Trigger next sample <-TriggerProfilingcomputer User-level daemonwrites to disk when buffer 7/8 full

11. System Monitor Kernel Mods • NetBSD • recording of PC and PID • fork(), exec(), exit() instrumented to record pathname associated with process • new system calls to control profiling • pscope_init(), pscope_start(), pscope_stop(), pscope_read() (user-level daemon, to disk)

12. Energy Analyzer • Voltage essentially constant, only current recorded. • Each sample is binned into process bucket and procedure within process bucket. • Energy calculated by summing each bucketE = Vmeas S ItDt n t=0

14. Framework for Adaptation • Odyssey project - Satya (CMU) • Odyssey is an attempt to incorporate application-aware adaptation • Noble et al, Agile application-aware adaptation for mobility, SOSP 97 (network bandwidth examples) • Flinn and Satya, Energy-aware adaptation for mobile applications, SOSP 99 (energy usage examples)

15. Odyssey Provides • API - new syscalls to register a window of tolerance for a variable resource (e.g. network bandwidth) • Notifications of change (upcalls) • Implies detection of changes. Mechanisms needed. • Typing - Wardens which handle type-specific functionality • Type awareness necessary to evaluate tradeoffs • Viceroy – centralized resource coordination

16. Architecture of Odyssey Client Warden Viceroy Warden Application Cache Mgt Kernel

17. Defined as the degree to which data presented to the client matches the original copy at the server. Trading fidelity for performance. Adaptation involves supporting multiple and diverse levels of fidelity. Low JPEG Quality 10 KB Grayscale 85KB Notion of Fidelity Original 116 KB Thumbnail 2KB

18. API

19. Example • Each movie in multiple tracks at different fidelity levels • Warden can switch between tracks to fit bandwidth requirements

20. Energy Resource • Monitoring to detect resource availabilityPowerscope • Using Odyssey for adaptation in this domain.

21. Fidelity for Energy? • Before investing in incorporating energy into Odyssey for adaptation, first determine whether Odyssey’s model of fidelity as the way to adapt has potential for energy savings. • Experiments showing that potential, hand-tuned based on Powerscope information.

22. Case Study Video applicationoriginal 12.1MB • Step 1lossy compressionB: 7MB, C: 2.8MB • Step 2: display size reduced from 320x240 to 160x120Asmall: 4.9MB, Csmall: 1MB • Step 3: WaveLAN put into standby mode when not used • Step 4: Disk powered off

23. Base case Every optimization

25. Conclusions about Fidelity as Energy Saving Adaptation • Significant variation in effectiveness of fidelity reduction among objects • And among applications • Combining hardware power management with fidelity reductions is good.

26. Can Odyssey Automate This? • User specifies target battery lifetime. • Odyssey is to monitor energy supply and demand • Notify applications to change fidelity if estimate future demand and supply don’t match to achieve desired lifetime.

27. Goal-directed Energy Adaptation • On-line version of Powerscope(assume this will be built-in) • Smoothed observations of pastconsumption as estimate of future. • Odyssey’s own criteria for notification EstDemand = ((1-a)(sample) + (a)(old)) * time_remaining

28. Results • Goals: • Meet specified battery lifetime • Highest fidelity within that constraint • Infrequent adaptations • Small leftover battery capacity at end of period.