Software and Energy Consumption

1. Software and Energy Consumption --- Issues, Models, and Approaches

2. Alloc Application Programs DeAlloc Execution Software and Hardware OS / System Software (Resource Manager) Hardware (Resources) What’s wrong with this abstraction? Sundar B.

3. Crosscutting Concerns and Solutions • Issue: Performance • E.g. Programmer must understand – i.e. app. Program must be aware of : • Paging behavior, Caching behavior, Pipelining/Superscalar etc. • Solution (partial): • Compiler performs lots of optimizations and provides configurable/dynamic options for programmer • But still hand tuning is not uncommon (as a requirement) - Broken abstraction? Sundar B.

4. Alternatives to caching; Thin virtual memories Uniform Cost I/O Thin file systems Embedded: Custom architectures Real-time: external clocking? Crosscutting Concerns and Solutions • Real-Time and Embedded Systems • OS’s were built on certain assumptions about resources • A strict von-Neumann model of architecture • Transparent Caching (Virtual Memory) • Asynchrony (e.g. I/O) All are broken abstractions! They percolate up to applications! Sundar B.

5. IPC Process Mgmt. Memory Mgmt. Apps. File System Networking OS Timer Hardware Signal Processor Core Micro-Processor Core Program RAM Data RAM Program RAM Glue Logic Communication H/W Signal Converters and Interfacing Typical Embedded System - Design Space T1 T3 T2 Sundar B.

6. Crosscutting Concerns and Solutions • Issues in RT-EMB systems: • Bounded Response times • Time tied to external clock (Synchronization) • Resource Limitations • Moore’s law for processors not useful here • RAM / Disk not necessarily cheap (e.g. Compare to cell phone cost curve) • Solution(s): • Redesign of OSes • Fair progress so far • Time/Resource aware languages, compilers, runtime environments • Fair theoretical progress, Limited practice • Time/Resource aware programmers • Are we asking for the impossible? Sundar B.

7. Crosscutting Concerns and Solutions • Issue in Mobile Embedded Systems • Power is on a ration! • What is (unwanted) power consumption? • Idle CPU • Excessive Memory/Storage access • Excessive Communication • Towards solution(s): • Better hardware / Architectures • Voltage Scaling, Frequency Scaling • Memory / Cache design • Configurable modules Sundar B.

8. Power and Software • Meta-Issues • Conflict between performance and power • Applicable for hardware as well, but users think hardware grows on trees • If grapes are sour they are sour, but what if grape juice is sour? • Relation between software execution and power consumption • Lack of good models or clear understanding! • Conflict between programmer productivity and power consumption • (see following slides) Sundar B.

9. Conflict: Productivity vs. Others • Application Software is built as layers of abstraction • E.g. Take one look at the Java web page. • Necessary for separation of concerns: • Hardware vendor provides firmware, Microsoft provides OS, others write applications one on top of another. • Improves programmer productivity but • reduces performance • ignores power requirements etc. Sundar B.

10. Operating System – Energy Model • Multiple Entry – Multiple Exit Program • Explicit: System Call Entry-Exit Paths • Implicit: Interrupt Entry-Exit Paths • Explicit Energy Costs • Cost of OS primitives (System functions) • Implicit Energy Costs • Hidden Costs – due to OS level activities but not due to functions activated by system calls. • Often associated with Interrupt Entry-Exit paths. Sundar B.

11. Operating Systems • Task Management • Scheduling, Context Switching • Memory Management • Paging (Virtual Memory), Software-aware Caching Sundar B.

12. Task Management • Scheduling in Real Time Systems • Processes have to meet deadlines • Typical algorithms (for periodic tasks): • Rate Monotonic, Earliest Deadline First • Overhead: Non-task power consumption: • Timer Interrupt / Signal Handling • Interrupt handler invocation; user mode to kernel model; signal priority resolution and signal handling. • Scheduling effort by the OS • Task selection; Queuing/dequeuing; • Pre-emption (Context Switching) • Direct Cost: Context Switching effort (process saving/loading) • Indirect Cost: Memory Hierarchy Impact (if data is not shared cache has to be flushed and refilled; pages in memory have to be saved and reloaded) Sundar B.

13. Data for Linux on ARM [Tan et. al. ] Task Management • Timer Interrupt / Signal Handling • 3500 nJ • Scheduling • 1200nJ • Context Switching • Direct Cost: 12000nJ • Indirect Cost: Depends on cache and locality • Exercise: • estimate power consumption due to a cache miss on the following context: a 4K on-Pentium-like-chip cache with LRU replacement of cache line from DRAM; Multiply the estimate by # cache lines (context switches could cause cold caches) • Measure the actual power consumption in a typical context switch scenario. Contrast: A C function with one loop of 8000 iterations of an addition costs 240000nJ Sundar B.

14. Power-aware Scheduling • Earliest reference: • Mok ’83 (MIT Thesis) • Focus: • Single Processor • Periodic Tasks • Worst Case Execution Time (WCET) known • Approaches: • Leveraging Hardware support • Reducing Context Switches • Exploiting Locality Sundar B.

15. Power Aware Scheduling [2] • Leveraging Hardware Support • RT systems are designed for WCET • Often WCET is rarely realized • Often WCET >> Common-Case Exec. Time • Implication: Considerable Slack Time • RT/Embedded systems are designed for quick response: • Task Periods are often estimated conservatively • Implication: Considerable Idle Time • Slack Times and Idle Times lead to unutilized CPU time • CPU can’t be put to sleep • due to RT response time considerations • And due to the fact individual intervals are small Sundar B.

16. Power Aware Scheduling [3] • Leveraging Hardware Support • DVS and DFS allow processor to execute at different rates • Implication: • Processes can be slowed down during slack times; • Processes can be started early and executed slowly during slack and idle times. • Approaches: • Dynamic Reclamation: Aydin et. Al • RT-DVS algorithm: Pillai and Shin • Feedback EDF: Dudani et. Al. • Limitations: • OS tightly coupled to Scaling system (Not bad??) • Can Scaling be done as frequently as claimed? • What are the implications? Sundar B.

17. Power Aware Scheduling [4] • Reducing Context Switches • Modified Least-Laxity First (MLLF) – Oh and Yang. • LLF introduces artificial context switches when laxity ties occur • MLLF removes these artificial switches. • Savings are also artificial?? • Modified Maximum Urgency First (MMUF) • variation of MLLF – dynamically switches between different algorithms • No better than MLLF in terms of power consumption. Sundar B.

18. Power Aware Scheduling [5] • Reducing Context Switches • Modified RM / EDF (Raveendran et. al) • Use RM or EDF but at each decision point • check whether the current task can be continued without impacting the deadline of any future task. • Significant context switch reduction • Simulation results very close to minimal (possible) context switches • Minimal modification to algorithms with known behavior (easy to implement and other factors) Sundar B.

19. Power Aware Scheduling [6] • Reducing Context Switches • Modified RM / EDF (Raveendran et. al) • Limitations: • Each decision takes worst case O(n*n) computations (Constant for RM, O(n) for EDF) • Reduced Context Switches does not necessarily mean reduced memory problems • Power savings in context switches is small compared to power savings due to reduced memory access • Open Problems: • Can we get absolute minimum? • Can we decide faster? • Can we quantify average case (expect around m*m where m is no. of jobs in queue) ? Sundar B.

20. Power Aware Scheduling [7] • Exploiting Locality • Periodic tasks: • Jobs of the same tasks use same instructions and possibly same data • Cooperating job sets: • Jobs of a set may share data (shared memory) Sundar B.

21. Power Aware Scheduling [8] • Exploiting Locality - Approaches: • Instruction Space: [A Wolfe.] • Data Space: [Kadayif and Kandemir group] • Arrays used by diff. processes (same appl.) – slicing of arrays such that switching within same slice is maximized. • Limitations: • Works only for array processing and for instruction cache. • Is Shared array processing that common in RT/embedded Systems? Sundar B.

22. Power Aware Scheduling [9] • Exploiting Locality • Data-independent scheduling heuristic? • Try to schedule “similar” jobs together • Context switches do not cause memory flush • Try to schedule “similar” jobs far apart • Reduce fragmentation of intervals. • Works very well in cache miss reduction • Limitations • Shcedulability not guaranteed!! • Open Problems • Good characterization, stable algorithm • Better simulation of memory behavior Sundar B.