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

Storage on Your Smartphone Uses More Energy Than You Think Jayashree Mohan, Dhathri Purohith, Matthew Halpern, Vijay Chidambaram, Vijay Janapa Reddy

2

Limited battery capacity is a major concern! However, battery density doubles only once every 10 years 3

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

Storage subsystem takes Measure energy 36% Differentially to segregate storage Of total energy for sub-system energy on a random IO intensive commercial smartphone. workload. Random writes take Random reads take 20x 8x more energy than more energy than sequential writes. sequential reads. 5

Outline  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

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 Samsung Galaxy nexus connected to Monsoon Power Monitor 8

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

Differential energy measurement Writes to In-memory internal eMMC writes over network Writes to in-memory filesystem Screen On, No background Apps, No IO IDLE STATE CPU AND NETWORK STORAGE MEMORY SUBSYSTEM 10

Overall Storage Energy Consumption  Energy consumed by storage subsystem is almost equal to the energy consumed by screen for an IO intensive workload. Screen 36.5% 37.0% CPU & Memory Network 0.6% 24.5% Storage 11

 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 12

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 900 500 450 800 Storage energy in uJ/KB Storage energy in uJ/KB 400 700 350 600 300 500 19X 250 400 200 300 150 12X 200 100 100 50 0 0 Seq Write Rand Write Seq Write Rand Write Ext4 F2FS 14

F2FS vs Ext4 : File ops 8X 7X Seq Read Rand Read Seq Read Rand Read Ext4 F2FS 15

F2FS vs Ext4: Write Amplification Ext4: Ext4  In-place updates. 72 ACTUAL IO AT THE BLOCK  Fsync forces both data and metadata to be written on to the disk. LAYER (IN MB)  Meta data includes:  Inode table  Journal transaction begin block  Journal transaction end block  list of blocks in the transaction. RANDOM WRITE (10MB) 16

F2FS vs Ext4: Write Amplification F2FS: F2FS  Log structured. 31  ACTUAL IO AT THE BLOCK Maintains NAT table for address translation. LAYER (IN MB)  Only data blocks and their direct node blocks are written after every fsync.  Meta data includes – File inodes, NAT and SIT updates. RANDOM WRITE (10MB) 17

F2FS vs Ext4: Read Amplification Ext4 Ext4: ACTUAL IO AT THE BLOCK  Android uses aggressive 195 read prefetching. LAYER (IN MB)  Blktrace reveals minimum size of read request is 8KB. RANDOM READ (100MB) 18

F2FS vs Ext4: Read Amplification F2FS 272 F2FS: ACTUAL IO AT THE BLOCK  Every read constitutes of a LAYER (IN MB) request to read direct node block and the data.  Every read request to direct node block results in NAT translation. RANDOM READ (100MB) 19

 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 20

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 7 6 Storage energy in mJ/Txn 1.5X 1.5X 5 4 3 2 1 0 Inserts Updates Deletes Ext4 F2FS 22

 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 23

Android applications  Applications Studied: Mail and Facebook  Duration traced: 180 seconds  Energy estimation:  Percentage of 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 60 50 % of randomness 40 30 20 10 0 Write Read Write Read Mail Facebook Ext4 F2FS Percentage of Random IO at block level 25

F2FS vs Ext4 : Android applications Ext4 F2FS ENERGY CONSUMED (IN J) 42.91 2.1X 20.07 14.13 1.6X 8.79 MAIL FACEBOOK Total energy consumed by storage for different Android applications 26

Implications for File System Design  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

Conclusions  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

29

Thank you! 30