Integrating Concurrency Control and Energy Management in Device Drivers
This content discusses the challenges, motivations, and existing operating system approaches in integrating concurrency control and energy management in device drivers. It highlights the importance of energy-efficient sensor networks and device power management techniques for optimal performance in various applications.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Integrating concurrency control and energy management in device drivers Kevin Klues, Vlado Handziski , Chenyang Lu, Adam Wolisz, David Culler, David Gay , and Philip Levis
Sensor Networks Sensor Networks Where can we find them? Simple answer: Everywhere!! Industrial applications: Petroleum Radiation detection (Japan) Global warming Weather forecasting (Sometimes they get it right!!!)
Challenges Challenges Ease of use Withstand Harsh environmental conditions Mobile Light weight Low power Small battery Energy Harvesting Communication failures Dynamic network topology Must run unattended from days to years
Motivation Motivation Traditional Embedded Operating Systems VxWorks Multicore, preemptive, blocking QNX Multicore, Microkernel architecture, POSIX eCos One process, preemptive, multiple threads TinyOS Single Thread/Stack, non-blocking Difficult to manage energy in traditional Operating Systems Hard to tell the OS about future application workloads All energy management logic pushed out to the application Optimal energy savings at cost of application complexity
Existing OS Approaches Existing OS Approaches Dynamic CPU Voltage Scaling Vertigo Application workload classes Grace OS Explicit real-time deadlines Disk Spin Down Coop-IO Application specified timeouts Energy Allocation Cinder Operating System Reserves and Taps ACPI OS directed configuration, power and thermal management of computing platforms
Device power management Device power management Device Drivers Power Management Mac OS X Linux 2.6 Windows ACPI Platform Independent Specification Hardware Support Function Fixed Hardware Interface relies on AML ACPI Component Architecture Global States: G0-G3, (G0)S0, (G1)S1-S4, (G2)S5 Processor States: C0-C3 Device States: D0-D3 Performance States: P0-Pn (C0, D0)
Overview Overview Concurrency Control Concurrency of I/O operations alone, not of threads in general Synchronous vs. Asynchronous I/O Asynchronous I/O can improve energy efficiency by allowing the OS to schedule it Energy Management Power state of device needed to perform I/O operations Determined by pending I/O requests using Asynchronous I/O
Overview Overview Concurrency Control Concurrency of I/O operations alone, not of threads in general Synchronous vs. Asynchronous I/O Asynchronous I/O can improve energy efficiency by allowing the OS to schedule it Energy Management Power state of device needed to perform I/O operations Determined by pending I/O requests using Asynchronous I/O
Integrated Concurrency and Energy Integrated Concurrency and Energy Management (ICEM) Management (ICEM) Device driver architecture that manages energy Implemented in TinyOS 2.0 Three driver classes: virtualized, shared, dedicated Power Locks: synchronization primitives which couple energy, configuration, and concurrency management. Component library: arbiters, power managers, and configurators. Advantages of ICEM Energy Efficient: within 1.6% of hand tuned implementation Reduces code complexity: 400 vs 68 lines (nesC)
Hardware Platform Hardware Platform CPU MSP430 8Mhz, 16-bit I2C, SPI, ADC 10kB Ram Radio CC2420 250kbps, 802.15.4 Flash ST M25P80 2Mb External Total Solar TSR Photodiode Photo Active PAR Photodiode Temperature and Humidity SHT11
Hardware Platform Hardware Platform Six Major I/O Devices Possible Concurrency I2C, SPI, ADC Energy Management Power on peripherals only when needed
Example Application Example Application Requirements Every 5 Minutes Sample all the sensors and log the readings to flash Every 12 Hours Retrieve new readings from flash and send to central collection unit Pseudocode
Example Application Example Application Work Flow Work Flow
Example Application Example Application Work Flow Work Flow
Example Application Example Application Work Flow Work Flow
Example Application Example Application Work Flow Work Flow
Example Application Example Application Work Flow Work Flow
Example Application Example Application Work Flow Work Flow
Example Application Example Application Work Flow Work Flow
Example Application Example Application Energy efficient application pseudo-code
Example Application Example Application Energy efficient application Pseudocode Device Power Control
Example Application Example Application Energy efficient application Pseudocode Device Wait Times
Example Application Example Application ICEM Application Look familiar? Removed device control from application
ICEM Attributes ICEM Attributes Three classes of drivers Virtualized Functional Interface Dedicated Functional and Power Interfaces Shared Functional and Lock Interfaces
Virtualized Device Driver Virtualized Device Driver Provides a Functional interface Assumes multiple users Implemented for higher-level users that can tolerate longer latencies Concurrency Control Implicit control through buffering requests Energy Management Implicit management based on pending requests
Dedicated Device Driver Dedicated Device Driver Provides a Functional and Power Control interface Assumes one user Implemented for lowest-level hardware independent abstractions Concurrency Control None Energy Management Explicit management through power control interface
Shared Device Driver Shared Device Driver Provides Functional and Lock interfaces Assumes multiple users Implemented for lower-level users that require stringent timing requirements Concurrency Control Explicit control through Lock requests Energy Management Implicit management base on pending requests
ICEM Attributes ICEM Attributes Three classes of drivers Virtualized Functional Interface Dedicated Functional and Power Interfaces Shared Functional and Lock Interfaces Power Locks Split phase locks with integrated energy and configuration management
Power Locks Power Locks Used to synchronize access to drivers between software components Idle Lock Turn off device Client could specify device configuration Client request a lock, provide a callback function when it is given the lock Deadlock problems could arise
Power Locks Power Locks
ICEM Attributes ICEM Attributes Three classes of drivers Virtualized Functional Interface Dedicated Functional and Power Interfaces Shared Functional and Lock Interfaces Power Locks Split phase locks with integrated energy and configuration management Component Library Arbiters manages I/O concurrency Configurators provides device specific configurations Power Managers provides energy management policy
Component Library Component Library Used to implement Power lock
Component Library Component Library Lock interface for concurrency control (FCFS, Round-Robin ArbiterConfigure interface for automatic hardware configuration DefaultOwner interface for automatic power management
Component Library Component Library Implement ArbiterConfigure Interface Call hardware specific configuration from dedicated driver
Component Library Component Library Implement DefaultOwner interface Power down device when device falls idle Power up device when lock request is received Provides Immediate and Deferred policies
Shared Example Driver Shared Example Driver MSP430 USART0 Three modes of operation - SPI, I2C, UART
Shared Example Driver Shared Example Driver MSP430 USART0 Three modes of operation - SPI, I2C, UART
Shared Example Driver Shared Example Driver MSP430 USART0 Three modes of operation - SPI, I2C, UART
Shared Example Driver Shared Example Driver MSP430 USART0 Three modes of operation - SPI, I2C, UART POWER LOCK
Drawbacks Drawbacks ICEM Overhead RAM and ROM Library components require additional code space and memory. CPU cycles calls utilizing shared drivers must go through arbiters, power managers.
Arbiter Overhead Arbiter Overhead Arbiter Overhead (RAM) 350 550 bytes Initial overhead Increases linearly with the number of clients
Arbiter Overhead Arbiter Overhead Arbiter Overhead (CPU)
Arbiter Overhead Arbiter Overhead Arbiter Overhead (CPU)
Arbiter Overhead Arbiter Overhead Arbiter Overhead (CPU)
Power Manager Overhead Power Manager Overhead Power manager library components RAM and ROM overhead Cycle count overhead
Drawbacks Drawbacks ICEM Overhead RAM and ROM Library components require additional code space and memory. CPU cycles calls utilizing shared drivers must go through arbiters. What does this overhead mean to power consumption?
Energy Overhead Energy Overhead Hand Tuned Most energy efficient ICEM All concurrent operations Serial+ Optimal serial ordering Serial- Worst Case serial ordering
Energy Overhead Energy Overhead Application Energy per Day 5 Minute sampling interval 12 hour send cycle
Energy Overhead Energy Overhead Average energy consumption
Energy Overhead Energy Overhead Overhead of ICEM vs Energy Efficient implementation ADC Timeout + Power Lock Overhead Overhead (Assume 288 samples per day) 2.9mAs/day ~= 1029 mAs/year 5.60% of total sampling energy 0.03% of total application energy
