Integrating Concurrency Control and Energy Management in Device Drivers Chenyang Lu
Why worry about energy? 16x Intel vs. Duracell 14x Processor (MIPS) 12x Hard Disk (capacity) 10x Improvement (compared to year 0) 8x Memory (capacity) 6x 4x Battery (energy stored) 2x 1x 0 1 2 3 4 5 6 Time (years) No Moore’s Law in batteries: 2-3%/year growth! 2
Low-Power Sensor Platforms The Mote Revolution: Low Power Wireless Sensor Network Devices, Joseph Polastre, Robert Szewczyk, Cory Sharp, David Culler, Hot Chips 16. 3
Power State Transitions Ø System view when switching from sleep to active Leaving/entering sleep states costs time & energy Source: J. Polastre, R. Szewczyk, C. Sharp, D. Culler. The Mote Revolution: Low Power Wireless Sensor Network Devices. In Hot Chips 16, 2004. 4
Overview Ø Concurrency Control: q Concurrency of I/O operations alone, not of threads in general q Synchronous vs. Asynchronous I/O Ø Energy Management: q Power state of devices needed to perform I/O operations q Determined by pending I/O requests using Asynchronous I/O read() Application read() write() OS write() Physical Flash Flash Driver read() setPowerState() read() 5
Overview Ø Concurrency Control: q Concurrency of I/O operations alone, not of threads in general q Synchronous vs. Asynchronous I/O Ø Energy Management: q Power state of devices needed to perform I/O operations q Determined by pending I/O requests using Asynchronous I/O The more workload information an application can give the OS, the more energy it can save. 6
Motivation Ø Difficult to manage energy in traditional OS q Hard to tell OS about future application workloads q API extensions for hints? 7
Existing OS Approaches Ø Dynamic CPU Voltage Scaling q Vertigo - Application workload classes q Grace OS - Explicit real-time deadlines Ø Disk Spin Down q Coop-IO - Application specified timeouts 8
Existing OS Approaches Ø Dynamic CPU Voltage Scaling q Vertigo - Application workload classes q Grace OS - Explicit real-time deadlines Ø Disk Spin Down q Coop-IO - Application specified timeouts Saving energy is a complex process 9
Existing OS Approaches Ø Dynamic CPU Voltage Scaling q Vertigo - Application workload classes q Grace OS - Explicit real-time deadlines Ø Disk Spin Down q Coop-IO - Application specified timeouts Saving energy is a complex process A little application knowledge can help us a lot 10
Sensor Networks Ø Domain in need of unique solution to this problem q Harsh energy requirements q Very small source of power (2 AA batteries) q Must run unattended from months to years 11
Sensor Networks Ø Domain in need of unique solution to this problem q Harsh energy requirements q Very small source of power (2 AA batteries) q Must run unattended from months to years Ø First generation IoT OSes (TinyOS, Contiki...) q Push all energy management to the application q Optimal energy savings at cost of application complexity 12
ICEM: Integrated Concurrency and Energy Management Ø Device driver architecture that automatically manages energy Ø Introduces Power Locks , split-phase locks with integrated energy and configuration management Ø Defines three classes of drivers: dedicated, shared, virtualized Ø Provides a component library for building drivers Ø Implemented in TinyOS 2.0 -- all drivers follow it 13
Advantages of ICEM Ø Energy efficient – 98.4% as hand-tuned implementation Ø Reduces code complexity – 400 vs. 68 lines of code Ø Enables natural decomposition of applications 14
The TelosB Platform Ø Six major I/O devices Ø Possible Concurrency q I 2 C, SPI, ADC Ø Energy Management q Turn peripherals on only when needed q Turn off otherwise 15
Representative Logging Application Producer Consumer Every 5 minutes: Write prior samples Every 12 hours: Sample photo active For all new entries: Flash Sample total solar Send current sample Sample temperature Read next sample Sample humidity Radio Sensors 16
Representative Logging Application Producer Consumer Every 5 minutes: Write prior samples Every 12 hours: Sample photo active For all new entries: Flash Sample total solar Send current sample Sample temperature Read next sample Sample humidity Radio Sensors 17
Representative Logging Application Producer Consumer Every 5 minutes: Write prior samples Every 12 hours: Sample photo active For all new entries: Flash Sample total solar Send current sample Sample temperature Read next sample Sample humidity Radio Sensors 18
Representative Logging Application Producer Consumer Every 5 minutes: Write prior samples Every 12 hours: Sample photo active For all new entries: Flash Sample total solar Send current sample Sample temperature Read next sample Sample humidity Radio Sensors 19
Representative Logging Application Producer Consumer Every 5 minutes: Write prior samples Every 12 hours: Sample photo active For all new entries: Flash Sample total solar Send current sample Sample temperature Read next sample Sample humidity Radio Sensors 20
Representative Logging Application Producer Consumer Every 5 minutes: Write prior samples Every 12 hours: Sample photo active For all new entries: Flash Sample total solar Send current sample Sample temperature Read next sample Sample humidity Radio Sensors 21
Representative Logging Application Producer Consumer Every 5 minutes: Write prior samples Every 12 hours: Sample photo active For all new entries: Flash Sample total solar Send current sample Sample temperature Read next sample Sample humidity Radio Sensors 22
Representative Logging Application Producer Consumer Every 5 minutes: Write prior samples Every 12 hours: Sample photo active For all new entries: Flash Sample total solar Send current sample Sample temperature Read next sample Sample humidity Radio Sensors 23
Representative Logging Application Producer Consumer Every 5 minutes: Write prior samples Every 12 hours: Sample photo active For all new entries: Flash Sample total solar Send current sample Sample temperature Read next sample Sample humidity Radio Sensors 24
Code Complexity Hand-Tuned Application Every 5 minutes: Turn on SPI bus Turn on flash chip Turn on voltage reference Turn on I 2 C bus Log prior readings Start humidity sample Wait 5ms for log Turn off flash chip Turn off SPI bus Wait 12ms for vref Turn on ADC Start total solar sample Wait 2ms for total solar Start photo active sample Wait 2ms for photo active Turn off ADC Turn off voltage reference Wait 34ms for humidity Start temperature sample Wait 220ms for temperature Turn off I 2 C bus 25
Code Complexity Hand-Tuned Application Every 5 minutes: Turn on SPI bus Turn on flash chip Turn on voltage reference Turn on I 2 C bus Log prior readings Start humidity sample Wait 5ms for log Turn off flash chip Turn off SPI bus Wait 12ms for vref Turn on ADC Start total solar sample Wait 2ms for total solar Start photo active sample Wait 2ms for photo active Turn off ADC Turn off voltage reference Wait 34ms for humidity Start temperature sample Wait 220ms for temperature Turn off I 2 C bus 26
Code Complexity Hand-Tuned Application Every 5 minutes: Turn on SPI bus Turn on flash chip Turn on voltage reference Turn on I 2 C bus Log prior readings Start humidity sample Wait 5ms for log Turn off flash chip Turn off SPI bus Wait 12ms for vref Turn on ADC Start total solar sample Wait 2ms for total solar Start photo active sample Wait 2ms for photo active Turn off ADC Turn off voltage reference Wait 34ms for humidity Start temperature sample Wait 220ms for temperature Turn off I 2 C bus 27
Code Complexity Hand-Tuned Application ICEM Application Every 5 minutes: Every 5 minutes: Turn on SPI bus Log prior readings Turn on flash chip sample humidity Turn on voltage reference sample total solar Turn on I 2 C bus sample photo active Log prior readings sample temperature Start humidity sample Wait 5ms for log Turn off flash chip Turn off SPI bus Wait 12ms for vref Turn on ADC Start total solar sample Wait 2ms for total solar Start photo active sample Wait 2ms for photo active Turn off ADC Turn off voltage reference Wait 34ms for humidity Start temperature sample Wait 220ms for temperature Turn off I 2 C bus 28
Split-Phase I/O Operations Ø Implemented within a single thread of control Ø Application notified of I/O completion through direct upcall Ø Driver given workload information before returning control Ø Example: read() à readDone() Application read() readDone() void readDone(uint16_t val) { Driver next_val = val; read(); I/O request I/O interrupt } 29
ICEM Architecture Ø Defines three classes of drivers q Virtualized – provide only functional interface q Dedicated – provide functional and power interface q Shared – provide functional and lock interface 30
Dedicated Device Drivers Ø Provide Functional and Power Control interfaces Ø Assume a single user Ø No concurrency control Ø Explicit energy management Ø Low-level hardware and bottom-level abstractions have a dedicated driver Dedicated Energy : Implicit Concurrency : None 31
Recommend
More recommend
