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

Energy/Power-related APIs OnNow and ACPI Odyssey

ACPI Advanced 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

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 G2-S5 Soft off Legacy G0-S0 working G3 mech off G1 Sleep S1 S2 S3 S4 Dx modem x Dx HDD x Dx cdrom x Cx cpu wakeup

Transmeta Crusoe ACPI Power States

Transmeta Crusoe Power

OSDM: OnNow Applications OS HW OnNow WIN32 ext ACPI Spec 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

Detecting and Timing Idleness Without source code (applications or OS). Idle process (lowest priority) while (space_left_in_buffer){ for(I=0; I<N; I++) ; // N s.t. loop takes 1ms. generate trace record; } Non-idle time is an elongated time between trace records AB CDE 1ms 10.7ms Busy for 9.7ms

Process State Transitions Ready Running in kernel Blocked Grant resource request Make ReadyToRun Make Running Schedule Sleep Request resource Yield or get preempted Create process Running user mode interrupt or exception Finish EvtGetEvent Event generated Busy Think time Wait time Can be sitting here with events queuedCan be blocked for synch I/O System support needed to track CPU status + eventqueue + synch I/O Single UI can lead to >1 events

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

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

Experimental Setup Data Gathering Multimeter’s clock drives sampling at period of 1.6ms  Trigger Profiling computer Takes current sample  Interrupt causes PC/PID sample to be buffered User-level daemon writes to disk when buffer 7/8 full  Trigger next sample

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)

Voltage essentially constant, only current recorded. Each sample is binned into process bucket and procedure within process bucket. Energy calculated by summing each bucket E  V meas S I t D t Energy Analyzer t=0 n

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)

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

Architecture of Odyssey Client Kernel Warden Viceroy Application Cache Mgt Warden

Odyssey Namespace odyssey movies db UNIX tome Mpeg tome SQL tome Leveraging the file system

Notion of Fidelity 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 Thumbnail 2KB Grayscale 85KB Original 116 KB

API

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

Examples Cellophane layer is the application seen by Odyssey – picks fidelity level Distillation server dynamically generates objects at specified fidelity

Examples Preprocessing has a compression ration of 5:1 Does this really fit the fidelity model?

Evaluation How agile is Odyssey for changing network bandwidth? –How do we measure agility? Do applications benefit from adaptation? How important is the centralized resource management (Viceroy)?

Resource Supply: Trace modulation to simulate 120 Kbytes/s and 40 Kbytes/s, synthetic workload Odyssey observing round-trip and throughput.

Benefits to Applications Video Web Browser Pref. metric is # dropped frames Perf. metric is ave time to fetch and display

How Important is the Global View of Resources? Per-application view Theoretical bandwidth passed to applications

Their Conclusions Collaborative approach between system and applications is important And feasible as shown by prototype Agility is key attribute Odyssey does a good job Centralized resource management is important Need to move beyond fidelity as the main adaptation response (as seen by speech example).

Energy Resource Monitoring to detect resource availability Powerscope Using Odyssey for adaptation in this domain.

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.

Case Study Video application original 12.1MB Step 1 lossy compression B: 7MB, C: 2.8MB Step 2: display size reduced from 320x240 to 160x120 A small : 4.9MB, C small : 1MB Step 3: WaveLAN put into standby mode when not used Step 4: Disk powered off

Base case Every optimization

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.

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.

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

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