1 / 22

Software and Energy Consumption

Software and Energy Consumption. --- Issues, Models, and Approaches. Alloc. Application Programs. DeAlloc. Execution. Software and Hardware. OS / System Software (Resource Manager). Hardware (Resources). What’s wrong with this abstraction?. Crosscutting Concerns and Solutions.

cybill
Télécharger la présentation

Software and Energy Consumption

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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.

More Related