Integrating Concurrency Control and Energy Management in Device - - PowerPoint PPT Presentation

▶
integrating concurrency control and energy management in
SMART_READER_LITE
LIVE PREVIEW

Integrating Concurrency Control and Energy Management in Device - - PowerPoint PPT Presentation

Aug 17, 2022 38 likes •812 views

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

slide-1
SLIDE 1

Integrating Concurrency Control and Energy Management in Device Drivers

Chenyang Lu

slide-2
SLIDE 2

Why worry about energy?

No Moore’s Law in batteries: 2-3%/year growth!

Processor (MIPS) Hard Disk (capacity) Memory (capacity) Battery (energy stored) 0 1 2 3 4 5 6 16x 14x 12x 10x 8x 6x 4x 2x 1x Improvement (compared to year 0) Time (years)

Intel vs. Duracell

2

slide-3
SLIDE 3

3

The Mote Revolution: Low Power Wireless Sensor Network Devices, Joseph Polastre, Robert Szewczyk, Cory Sharp, David Culler, Hot Chips 16.

Low-Power Sensor Platforms

slide-4
SLIDE 4

Power State Transitions

Ø System view when switching from sleep to active

4

Source: J. Polastre, R. Szewczyk, C. Sharp, D. Culler. The Mote Revolution: Low Power Wireless Sensor Network Devices. In Hot Chips 16, 2004.

Leaving/entering sleep states costs time & energy

slide-5
SLIDE 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

5

OS Flash Driver Physical Flash

read() write() setPowerState()

Application

read() write() read() read()

slide-6
SLIDE 6

Overview

6

Ø 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.

slide-7
SLIDE 7

Motivation

ØDifficult to manage energy in traditional OS

q Hard to tell OS about future application workloads q API extensions for hints?

7

slide-8
SLIDE 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

8

slide-9
SLIDE 9

Existing OS Approaches

9

Saving energy is a complex process

Ø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
slide-10
SLIDE 10

Existing OS Approaches

10

Saving energy is a complex process A little application knowledge can help us a lot

Ø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
slide-11
SLIDE 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

11

slide-12
SLIDE 12

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

slide-13
SLIDE 13

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

slide-14
SLIDE 14

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

slide-15
SLIDE 15

The TelosB Platform

Ø Six major I/O devices Ø Possible Concurrency

q I2C, SPI, ADC

Ø Energy Management

q Turn peripherals on only when needed q Turn off otherwise

15

slide-16
SLIDE 16

Representative Logging Application

16

Every 12 hours: For all new entries: Send current sample Read next sample

Flash Consumer Sensors Radio

Every 5 minutes: Write prior samples Sample photo active Sample total solar Sample temperature Sample humidity

Producer

slide-17
SLIDE 17

17

Every 12 hours: For all new entries: Send current sample Read next sample

Flash Consumer Sensors Radio

Every 5 minutes: Write prior samples Sample photo active Sample total solar Sample temperature Sample humidity

Producer

Representative Logging Application

slide-18
SLIDE 18

18

Every 12 hours: For all new entries: Send current sample Read next sample

Flash Consumer Sensors Radio

Every 5 minutes: Write prior samples Sample photo active Sample total solar Sample temperature Sample humidity

Producer

Representative Logging Application

slide-19
SLIDE 19

19

Every 12 hours: For all new entries: Send current sample Read next sample

Flash Consumer Sensors Radio

Every 5 minutes: Write prior samples Sample photo active Sample total solar Sample temperature Sample humidity

Producer

Representative Logging Application

slide-20
SLIDE 20

20

Every 12 hours: For all new entries: Send current sample Read next sample

Flash Consumer Sensors Radio

Every 5 minutes: Write prior samples Sample photo active Sample total solar Sample temperature Sample humidity

Producer

Representative Logging Application

slide-21
SLIDE 21

21

Every 12 hours: For all new entries: Send current sample Read next sample

Flash Consumer Sensors Radio

Every 5 minutes: Write prior samples Sample photo active Sample total solar Sample temperature Sample humidity

Producer

Representative Logging Application

slide-22
SLIDE 22

22

Every 12 hours: For all new entries: Send current sample Read next sample

Flash Consumer Sensors Radio

Every 5 minutes: Write prior samples Sample photo active Sample total solar Sample temperature Sample humidity

Producer

Representative Logging Application

slide-23
SLIDE 23

23

Every 12 hours: For all new entries: Send current sample Read next sample

Flash Consumer Sensors Radio

Every 5 minutes: Write prior samples Sample photo active Sample total solar Sample temperature Sample humidity

Producer

Representative Logging Application

slide-24
SLIDE 24

24

Every 12 hours: For all new entries: Send current sample Read next sample

Flash Consumer Sensors Radio

Every 5 minutes: Write prior samples Sample photo active Sample total solar Sample temperature Sample humidity

Producer

Representative Logging Application

slide-25
SLIDE 25

Code Complexity

25 Every 5 minutes: Turn on SPI bus Turn on flash chip Turn on voltage reference Turn on I2C 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 I2C bus

Hand-Tuned Application

slide-26
SLIDE 26

Code Complexity

26 Every 5 minutes: Turn on SPI bus Turn on flash chip Turn on voltage reference Turn on I2C 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 I2C bus

Hand-Tuned Application

slide-27
SLIDE 27

Code Complexity

27 Every 5 minutes: Turn on SPI bus Turn on flash chip Turn on voltage reference Turn on I2C 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 I2C bus

Hand-Tuned Application

slide-28
SLIDE 28

Code Complexity

28

Every 5 minutes: Log prior readings sample humidity sample total solar sample photo active sample temperature

ICEM Application

Every 5 minutes: Turn on SPI bus Turn on flash chip Turn on voltage reference Turn on I2C 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 I2C bus

Hand-Tuned Application

slide-29
SLIDE 29

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()

29

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

void readDone(uint16_t val) { next_val = val; read(); }

slide-30
SLIDE 30

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

slide-31
SLIDE 31

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

31

Energy: Implicit Concurrency: None Dedicated

slide-32
SLIDE 32

Virtualized Device Drivers

Ø Provide only a Functional interface Ø Assume multiple users Ø Implicit concurrency control through buffering requests Ø Implicit energy management based on pending requests Ø Implemented for higher-level services that can tolerate long latencies

32

Energy: Implicit Concurrency: Implicit Virtualized

slide-33
SLIDE 33

Shared Device Drivers

Ø Provide Functional and Lock interfaces Ø Assume multiple users Ø Explicit concurrency control through Lock request Ø Implicit energy management based on pending requests Ø Used by users with stringent timing requirements

33

Energy: Implicit Concurrency: Explicit Shared

slide-34
SLIDE 34

ICEM Architecture

34

  • Defines three classes of drivers

w Virtualized – provide only functional interface w Dedicated – provide functional and power interface w Shared – provide functional and lock interface

  • Power Locks, split-phase locks with integrated energy and

configuration management

slide-35
SLIDE 35

Power Locks

35

Dedicated Driver

Power Locks

Power Control HW-Specific Configuration Lock Functional

slide-36
SLIDE 36

Power Locks

36

Dedicated Driver

Power Locks

Power Control HW-Specific Configuration Lock Functional

slide-37
SLIDE 37

Power Locks

37

Dedicated Driver

Power Locks

Power Control HW-Specific Configuration Lock Functional

slide-38
SLIDE 38

Power Locks

38

Dedicated Driver

Power Locks

Power Control HW-Specific Configuration Lock Functional

slide-39
SLIDE 39

Power Locks

39

Dedicated Driver

Power Locks

Power Control HW-Specific Configuration Lock Functional

slide-40
SLIDE 40

Power Locks

40

Dedicated Driver

Power Locks

Power Control HW-Specific Configuration Lock Functional

slide-41
SLIDE 41

Power Locks

41

Dedicated Driver

Power Locks

Power Control HW-Specific Configuration Lock Functional

slide-42
SLIDE 42

Power Locks

42

Dedicated Driver

Power Locks

Power Control HW-Specific Configuration Lock Functional

slide-43
SLIDE 43

Power Locks

43

Dedicated Driver

Power Locks

Power Control HW-Specific Configuration Lock Functional

slide-44
SLIDE 44

Power Locks

44

Dedicated Driver

Power Locks

Power Control HW-Specific Configuration Lock Functional 1 2 3

slide-45
SLIDE 45

Power Locks

45

Dedicated Driver

Power Locks

Power Control HW-Specific Configuration Lock Functional Lock

slide-46
SLIDE 46

Power Locks

46

Dedicated Driver

Power Locks

Power Control HW-Specific Configuration Lock Functional

slide-47
SLIDE 47

Power Locks

47

Dedicated Driver

Power Locks

Power Control HW-Specific Configuration Lock Functional

slide-48
SLIDE 48

ICEM Architecture

48

  • Defines three classes of drivers

w Virtualized – provide only functional interface w Dedicated – provide functional and power interface w Shared – provide functional and lock interface

  • Power Locks, split-phase locks with integrated energy and

configuration management

  • Component library

w Arbiters – manage I/O concurrency w Configurators – setup device specific configurations w Power Managers – provide automatic power management

slide-49
SLIDE 49

Component Library

49

Lock

Power Locks

Power Control HW-Specific Configuration

slide-50
SLIDE 50

Component Library

50

Lock Power Control HW-Specific Configuration Arbiter Arbiter Configure Default Owner Configurator Power Manager

slide-51
SLIDE 51

Component Library

51

Power Control HW-Specific Configuration Arbiter Arbiter Configure Default Owner Configurator Power Manager Lock

n Lock interface for concurrency control (FCFS, Round-Robin) n ArbiterConfigure interface automatic hardware configuration n DefaultOwner interface for automatic power management

slide-52
SLIDE 52

Component Library

52

Power Control HW-Specific Configuration Arbiter Arbiter Configure Default Owner Configurator Power Manager Lock

n Lock interface for concurrency control (FCFS, Round-Robin) n ArbiterConfigure interface automatic hardware configuration n DefaultOwner interface for automatic power management

slide-53
SLIDE 53

Component Library

53

Power Control HW-Specific Configuration Arbiter Arbiter Configure Default Owner Configurator Power Manager Lock

n Implement ArbiterConfigure interface n Call hardware specific configuration from dedicated driver

slide-54
SLIDE 54

Component Library

54

Power Control HW-Specific Configuration Arbiter Arbiter Configure Default Owner Configurator Power Manager Lock

n Implement DefaultOwner interface n Power down device when device falls idle n Power up device when new lock request comes in n Currently provide Immediate and Deferred policies

slide-55
SLIDE 55

Shared Driver Example

Ø Msp430 USART (Serial Controller)

q Three modes of operation – SPI, I2C, UART

55

slide-56
SLIDE 56

Shared Driver Example

Ø Msp430 USART (Serial Controller)

q Three modes of operation – SPI, I2C, UART

56

Msp430 USART Power Control Functional Configuration

slide-57
SLIDE 57

Shared Driver Example

Ø Msp430 USART (Serial Controller)

q Three modes of operation – SPI, I2C, UART

57

Arbiter Immediate Power Manager SPI User Msp430 USART SPI Configurator Power Control Functional Configuration Lock

slide-58
SLIDE 58

Shared Driver Example

Ø Msp430 USART (Serial Controller)

q Three modes of operation – SPI, I2C, UART

58

Uart Configurator Arbiter Immediate Power Manager SPI User Msp430 USART SPI Configurator Uart User I2C User I2C Configurator Power Control Functional Configuration Lock

slide-59
SLIDE 59

Virtualized Driver Example

Ø Flash Storage

59

Arbiter Immediate Power Manager SPI User Log User Flash Driver Log Virtualizer Lock Power Control Functional

slide-60
SLIDE 60

Virtualized Driver Example

Ø Flash Storage

60

Arbiter Immediate Power Manager SPI User Log User Flash Driver Log Virtualizer Lock Power Control Functional

slide-61
SLIDE 61

Virtualized Driver Example

Ø Flash Storage

61

Arbiter Immediate Power Manager SPI User Log User Flash Driver Log Virtualizer Lock Power Control Functional

slide-62
SLIDE 62

Virtualized Driver Example

Ø Flash Storage

62

Arbiter Immediate Power Manager SPI User Log User Flash Driver Log Virtualizer Lock Power Control Functional

slide-63
SLIDE 63

Virtualized Driver Example

Ø Flash Storage

63

Arbiter Immediate Power Manager SPI User Log User Flash Driver Log Virtualizer Lock Power Control Functional

slide-64
SLIDE 64

Virtualized Driver Example

Ø Flash Storage

64

Arbiter Immediate Power Manager SPI User Log User Flash Driver Log Virtualizer Lock Power Control Functional

slide-65
SLIDE 65

Virtualized Driver Example

Ø Flash Storage

65

Arbiter Immediate Power Manager SPI User Log User Flash Driver Log Virtualizer Lock Power Control Block Virtualizer Block User

slide-66
SLIDE 66

Virtualized Driver Example

Ø Flash Storage

66

Arbiter Immediate Power Manager SPI User Flash Driver Lock Power Control Log User Log Virtualizer Block Virtualizer Block User

slide-67
SLIDE 67

Applications

Ø Hand Tuned – Most energy efficient Ø ICEM – All concurrent operations Ø Serial + – Optimal serial ordering Ø Serial - – Worst case serial ordering

67

Every 12 hours: For all new entries: Send current sample Read next sample

Flash Consumer Sensors Radio

Every 5 minutes: Write prior samples Sample photo active Sample total solar Sample temperature Sample humidity

Producer

slide-68
SLIDE 68

Tmote Energy Consumption

68

Average energy consumption for application operations

slide-69
SLIDE 69

Application Energy Consumption

69

Application energy with 5 minute sampling interval and

  • ne send batch every 12 hours

25 50 75 100 288 Samples 2 Sends E (mAs) Hand Tuned ICEM Serial + Serial -

slide-70
SLIDE 70

Application Energy Consumption

70

Application energy with 5 minute sampling interval and

  • ne send batch every 12 hours

25 50 75 100 288 Samples 2 Sends E (mAs) Hand Tuned ICEM Serial + Serial -

slide-71
SLIDE 71

Application Energy Consumption

71

Application energy with 5 minute sampling interval and

  • ne send batch every 12 hours

25 50 75 100 288 Samples 2 Sends E (mAs) Hand Tuned ICEM Serial + Serial -

slide-72
SLIDE 72

Sampling Power Trace

72

Overhead of ICEM to Hand-Tuned Implementation = ADC Timeout + Power Lock Overheads With 288 samples per day ≈ 2.9 mAs/day ≈ 1049 mAs/year Insignificant compared to total 5.60%

  • f total sampling energy

0.03%

  • f total application energy
slide-73
SLIDE 73

Expected Node Lifetimes

73

slide-74
SLIDE 74

Expected Node Lifetimes

74

slide-75
SLIDE 75

Expected Node Lifetimes

75

slide-76
SLIDE 76

Evaluation Conclusions

ØConclusions about the OS

q Small RAM/ROM overhead q Small computational overhead q Efficiently manages energy when given enough information

ØConclusions for the developer

q Build drivers with short power down timeouts q Submit I/O requests in parallel

76

slide-77
SLIDE 77

ICEM

Integrated Concurrency and Energy Management

Ø Device driver architecture for low power devices Ø At least 98.4% as energy efficient as hand-tuned implementation of representative application Ø Simplifies application and driver development Ø Questions the assumption that applications must be responsible for all energy management and cannot have a standardized OS with a simple API

77

  • K. Klues,
  • V. Handziski, C. Lu, A. Wolisz, D. Culler, D. Gay and P. Levis, Integrating

Concurrency Control and Energy Management in Device Drivers, ACM Symposium on Operating System Principles (SOSP'07), October 2007.