Storage on Your Smartphone Uses More Energy Than You Think - - PowerPoint PPT Presentation

Jayashree Mohan, Dhathri Purohith, Matthew Halpern, Vijay Chidambaram, Vijay Janapa Reddy

Storage on Your Smartphone Uses More Energy Than You Think

2

Limited battery capacity is a major concern! However, battery density doubles

• nly once every 10 years

3

What consumes battery? Usual suspects: screen, network Is storage a major contributor?

4

Random writes take

20x

more energy than sequential writes. Storage subsystem takes

36%

Of total energy for random IO intensive workload. Random reads take

8x

more energy than sequential reads.

Measure energy

Differentially

to segregate storage sub-system energy on a commercial smartphone.

5

• Overview
• How do we measure storage energy?
• Energy at different layers of storage stack

 File IO Operations  SQLite Operations  Android applications

• Implications for File System Design
• Conclusions

6

Outline

Tools to measure energy

• Software Based:

 Battery sensor: Periodically check current battery level  Apps: Requires power models.  Very crude measure.  Cannot detect small consumptions.

• Hardware Based:

 More fine-grained measure.  Requires specialized hardware to get component-wise energy.

7

Experimental setup

8

Samsung Galaxy nexus connected to Monsoon Power Monitor

Differential Energy Analysis

• Hardware tools provide fine-grained energy

measurements, but not component-wise.

• Design

experiments to measure energy “differentially”.

• IO intensive Workload: 100 MB of random

writes of IO size 4KB.

9

IDLE STATE CPU AND MEMORY NETWORK STORAGE SUBSYSTEM

10

Differential energy measurement

Screen On, No background Apps, No IO Writes to in-memory filesystem In-memory writes over network Writes to internal eMMC

Overall Storage Energy Consumption

• Energy consumed by storage subsystem is almost

equal to the energy consumed by screen for an IO intensive workload.

11

37.0% 0.6% 24.5% 36.5%

Screen CPU & Memory Network Storage

12

• Overview
• How do we measure storage energy?
• Energy at different layers of storage stack

 File IO Operations  SQLite Operations  Android applications

• Implications for File System Design
• Conclusions

File IO operations

Sequential IO Workload:

• IO Size : 512KB blocks.
• Total IO : 1GB of file reads and writes.

Random IO Workload:

• IO Size : 4KB blocks.
• Total IO : 100MB of file reads and writes.
• Fsync issued after every IO request.

13

F2FS vs Ext4 : File ops

14

100 200 300 400 500 600 700 800 900

Seq Write Rand Write Storage energy in uJ/KB Ext4

19X

50 100 150 200 250 300 350 400 450 500

Seq Write Rand Write Storage energy in uJ/KB F2FS

12X

F2FS vs Ext4 : File ops

15

Seq Read Rand Read Ext4

7X

Seq Read Rand Read F2FS

8X

F2FS vs Ext4: Write Amplification

72 RANDOM WRITE (10MB)

ACTUAL IO AT THE BLOCK LAYER (IN MB)

Ext4

16

Ext4:

• In-place updates.
• Fsync forces both data and metadata

to be written on to the disk.

• Meta data includes:

 Inode table  Journal transaction begin block  Journal transaction end block  list of blocks in the transaction.

F2FS vs Ext4: Write Amplification

31 RANDOM WRITE (10MB)

ACTUAL IO AT THE BLOCK LAYER (IN MB)

F2FS

17

F2FS:

• Log structured.
• Maintains NAT table for

address translation.

• Only data blocks and their

direct node blocks are written after every fsync.

• Meta data includes – File

inodes, NAT and SIT updates.

18

195 RANDOM READ (100MB)

ACTUAL IO AT THE BLOCK LAYER (IN MB)

Ext4

F2FS vs Ext4: Read Amplification

Ext4:

• Android uses aggressive

read prefetching.

• Blktrace reveals minimum

size of read request is 8KB.

19

272 RANDOM READ (100MB)

ACTUAL IO AT THE BLOCK LAYER (IN MB)

F2FS

F2FS vs Ext4: Read Amplification

F2FS:

• Every read constitutes of a

request to read direct node block and the data.

• Every read request to

direct node block results in NAT translation.

20

• Overview
• How do we measure storage energy?
• Energy at different layers of storage stack

 File IO Operations  SQLite Operations  Android applications

• Implications for File System Design
• Conclusions

SQLite operations

Workload:

• Prepopulate 1M entries.
• 15K each of SQLite Inserts, Updates and

Deletes.

• SQLite record size : 4KB.
• WAL-NORMAL

21

F2FS vs Ext4 : SQLite Operations

22

1 2 3 4 5 6 7 Inserts Updates Deletes Storage energy in mJ/Txn Ext4 F2FS

1.5X 1.5X

23

• Overview
• How do we measure storage energy?
• Energy at different layers of storage stack

 File IO Operations  SQLite Operations  Android applications

• Implications for File System Design
• Conclusions

Android applications

• Applications Studied: Mail and Facebook
• Duration traced: 180 seconds
• Energy estimation:

 Percentage

• f

random and sequential IO is computed using blktrace.  Sequential IO between two flushes are merged.  IO size < 32KB after merge is tagged as random.  Application energy consumption is estimated using File IO energy stats.

24

F2FS vs Ext4 : Android applications

25

Percentage of Random IO at block level

10 20 30 40 50 60 Write Read Write Read % of randomness Mail Facebook Ext4 F2FS

F2FS vs Ext4 : Android applications

26

Total energy consumed by storage for different Android applications

42.91 14.13 20.07 8.79 MAIL FACEBOOK ENERGY CONSUMED (IN J) Ext4 F2FS

1.6X 2.1X

• Use sequential IO

 F2FS still performs around 20-28% of random writes and about 12-20% of random reads.  Sequentializing the last 20-28% of random writes in F2FS can reduce energy consumption by half.

• Account

for trade-off between sequential writes and random reads.

• Use compression to reduce IO.

27

Implications for File System Design

• Differential

analysis gives component-wise energy measurements on commercial phones.

• Contribution of storage to energy consumption

in Android is significant - 36%!

• Huge energy benefits by sequentializing I/O.
• F2FS can be made significantly more energy-

efficient.

28

Conclusions

29

Thank you!

30