Marcin Miete Based on K. Klues, V. Handziski, C. Lu, A. Wolisz, D. - - PowerPoint PPT Presentation

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

• f 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

 Depending on the hardware OSes can do sampling

• perations 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 non­blocking

• perations because of limited RAM

PRODUCER Every 5 minutes: Write prior samples Sample photo active Sample total solar Sample temperature Sample humidity CONSUMER Every 12 hours: For all new log entries: Send current sample Read next sample

Siplit-phase operations

 Asynchronous I/O with one difference:

application making split­phase receives explicit notifications (upcall) about its completion.

 It allows a device driver to know

exactly when an application has been notified about the completion of an I/O event.

 ICEM uses this knowledge to control

device's power state.

Application Driver Read() readDone() I/O request I/O interrupt

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: data­link 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

 Support single user  For low­level hardware resources  Give single user complete control over requests and

energy management

 May provide explicit power control interface.

Dedicated

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 split­phase (TinyOS does not have

blocking calls)

 Each lock in system has set of candidate holders

(fixed at compile­time … TinyOS can create components only in compile­time)

Split-phase Power Locks

 Lock request are non­blocking (split­phase)  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 split­phase 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. ↔

Start() Client request lock relese lock startDone()

Interfaces to control energy:

• StdControl (single-phase control)
• SplitControl (split-phase control)

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

 RR arbiter

• 1. Instantiate ADC

client and his Config.

• 2. request ADC

sample

• 3. Request lock
• 8. Lock

granted

• 7. Configure ADC
• 9. Request

sample

• 5. Turn on
• 4. Request

lock

• 6. relese

lock

• 11. relese

lock 10.sample done

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 (hand­tuned 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?