Integrating Concurrency Control and Energy Management in Device Drivers Marcin Mieteń Based on K. Klues, V. Handziski, C. Lu, A. Wolisz, D. Culler, D. Gay, and P. Levis: “Integrating Concurrency Control and Energy Management in Device Drivers ,” in Proceedings SOSP 2007, Stevenson, WA, USA, October 2007.
First look at the problem Concurrency Control of I/O operations Energy Management – power state of devices is determined by pending, asynchronous I/O requests
Sensornets – motivation Energy management is a critical concern in wireless sensornets (small source of power, must run from months to years). First generation sensornet Oses (TinyOS, Contiki, Mantis) Push all energy management to the application Optimal energy saving at cost of application complexity.
● ICEM ( Integrated Concurrency Control and Energy Management) A device driver architecture that enables simple, energy efficient wireless sensornet applications. Simple API Sensornet applications don't have to be responsible for all power management Implemented in TinyOS 2.0
Energy management OS can improve energy efficiency by putting peripherals into low power modes and dropping process to a sleep state when idle. We have many researches about saving energy in OS but... Most modern operating system still use very simplistic energy management policies.
Hardware T2 on the telos 8MHz 16 bit CPU 250kbps 802.15.4 radio 2 MB external flash 10kB of RAM
What we have 6 major I/O devices (sensors) Possible Concurrency: I2C, SPI, ADC Energy management turn on peripherals only when needed
Concurrency opportunities I2C –2 digital sensors use it ADC – 2 analog sensors use it OS can concurrently sample 1 digital and 1 analog sensor Radio only need a SPI bus when loadin a packet into transmit memory In MSP 430 tree bus protocols I2C, SPI and UART share a common set of I/O pins
Energy management In many OSes energy efficiency comes at the cost of application code complexity. Many code lines with cases such as: “if forwarding a packet, defer powering down” ICEM – allows a sensornet OS to automatically minimize energy consumption without requiring additional explicit information from an application. 500 lines of code → using ICEM it would by fewer then 50 lines
Running example
Hand-Tuned vs ICEM ICEM energy efficient >= 98,4% hand tuned implmentation
● Concurrency PRODUCER CONSUMER Every 5 minutes: Every 12 hours: Write prior samples For all new log entries: Sample photo active Send current sample Sample total solar Read next sample Sample temperature Sample humidity Depending on the hardware OSes can do sampling operations concurrently. Concurrency reduces how long the producer part of the application stays awake when sampling. To achieve it producer's 5 operations should be non blocking or run one thread per operation. Sensornets usually use saplit-phase nonblocking operations because of limited RAM
Siplit-phase operations Asynchronous I/O with one difference: Application application making splitphase receives explicit notifications (upcall) Read() readDone() about its completion. Driver It allows a device driver to know exactly when an application has been I/O I/O request interrupt notified about the completion of an I/O event. ICEM uses this knowledge to control device's power state.
ICEM concurrency classes Virtualized Dedicated Shared
● Virtualized Support multiple users Buffer requests Give clients the appearance of independence For higher level services that can tolerate latency. For example: datalink packet sender is virtualized driver. Buffers requests and services them with a round robin policy. Driver can control power stated (power on when pending requests)
Dedicated Dedicated Support single user For lowlevel hardware resources Give single user complete control over requests and energy management May provide explicit power control interface.
Shared Provide explicit concurrency Users must contend for the driver through lock Calling commands on shared drivers without holding lock is an error. Some clients are trusted (unchecked) and some are not trusted (checked) Buffer lock request (Virtualized drivers buffer functional request e.g. send a packet) Arbiter is an ICEM library component.
Split-phase Power Locks
Split-phase Power Locks ICEM use shared drivers with power locks Power locks couple energy, configuration and concurrency management. Turn device off if lock falls idle. Allow a client to specify a device configuration before an arbiter grants him the lock. Lock must be splitphase (TinyOS does not have blocking calls) Each lock in system has set of candidate holders (fixed at compiletime … TinyOS can create components only in compiletime)
Split-phase Power Locks Lock request are nonblocking (splitphase) We can request several locks in parallel. Upcalls for lock could come in different order then requests. It could cause deadlock. Client 1: lock1, lock2, ?(upcall1 and upcall 2) Client 2: lock1, lock2, ?(upcall1 and upcall 2) upcall 1 to client 1, upcall 2 to client 2 == deadlock
ICEM Component Library ICEM provides a library of components that allow to implement power locks in device drivers. The library has three types of components:
Power Lock Power Lock
Power Lock components
Arbiter Power locks core component Provide splitphase lock interface that arbitrates between outstanding requests Determines its request queueing policy(RR or FCFS) When no one use lock Arbiter grant it to Default owner (DO). When DO has lock and somebody want to get lock then arbiter sends callback to DO. Before granting lock for user (and sending callback to him) Arbiter use corresponding configuration interface.
Power Managers Implement the DefaultOwne interface and use explicit power interfaces. Specifies a power lock's energy management policy. 2 power manager policies: immediate and deferred 3 interfaces to control energy Device on ↔ Power Managers has not lock. Client Interfaces to control energy: request lock Start() ● StdControl (single-phase control) relese lock ● SplitControl (split-phase control) startDone()
Configurators Implementing Configuration interface that arbiter use Allow clients to run some preambles before granting locks. One implementation can serve the same code preamble for many clients. Configurators are device specific Mega128 ADC, MSP430 ADC, SPI, USART, I2C
Power Lock components
ADC driver example 1. Instantiate ADC RR arbiter client and his Config. 2. request ADC 3. Request lock sample 11. relese lock 8. Lock granted 10. sample 9 . Request done sample 4. Request 7. Configure ADC lock 6. relese lock 5. Turn on
USART example
Energy consumption Serial+ - Optimal I/O ordering Serial- - the worst case I/O ordering
Lifetime
Lifetime
Livetime
ICEM waste energy Stays in active mode due to power lock Timeouts (handtuned imp. knows to turn off immediately when device is no more needed) Additional 1800 cycles per sample due to arbiter
Sleep Energy Management The second part of an efficient energy management strategy is to control the sleep state of node's microcontroller. Microcontrollers have spectrum of low power modes. Power mode has to be enough high to run all actually used peripherals. Computing the lowest power state of microcontroller requires system width information and can be complex and costly.
ICEM Sleep Energy Management Every controller have function calculating the lowest safe power state (based on enabled devices) OS compute this function only when dirty bit is on Drivers set dirty bit when they touch hardware. Drivers can specify a minimum safe sleep state hook
Questions?
Recommend
More recommend