I/O Stack Optimization for Smartphones

1. I/O Stack Optimization for Smartphones 2013. 10. 28 Mobile Lab 박세준

2. Contents • Intro • Past work • Elimination of JOJ • External Journaling • Polling based I/O • Evaluation • Related Work & Conclusion

3. Intro Ref: sqlite.org • Android adopts DB • Featherweight file-based DB(It’s rather DB API than DBMS) Minimum library size is <300KB, max up to <500KB • Provides journaling, to support atomic transaction action • Widely used • Web browsers: Firefox, Chrome, Opera • Web language: HTML5(default web storage), python • OS : Blackberry, Windows phone, iOS, Android, Symbian, WebOS, … Nevertheless..

4. Ref: https://ext4.wiki.kernel.org/index.php/Main_Page https://lkml.org/lkml/2008/8/1/217 Intro • Ext4 • A default file system since LINUX kernel ver. 2.6.28 • Introduces journaling also due to improve reliability • Became default Android file system from ICS, ver. 4.0.4 • Replaces rootfs for Linux kernel, YAFFS2 for previous internal flash, FAT32 for external SD • Using MTP(Media Transfer Protocol) to interface between Ext4 external SD and NTFS for windows • Has criticism Theodore, Developer of Ext4, stated that btrfs is better because there are more advanced technique in btrfs than Ext4

5. Intro % about overall 30% 70% 90% 75% 64%

6. Past work • Revisiting storage for smartphones Web cache tend to write sequentially, not on SQLite. -> Caused by different characteristic that web cache varies by pages, but SQLite reuses specific DB in address so that locality couldn’t be demonstrated (Continuous big page contents, Discrete much smaller chunks) In addition, almost SQLite write requests are synchronous, and they cause I/O delay in committing atomic operations

7. Past work • Revisiting storage for smartphones • Two improvement factors • fsync • Alleviation too frequent sync • DB in RAM • Write performance : NAND flash << RAM • Improvement write performance itself

8. Past work • Revisiting storage for smartphones Treat random write as sequential write Lazy evaluation

9. Past work • Revisiting storage for smartphones Nilfs : Log structured file system PCM : Phase-Change Memory, a kind of NVRAM(Non-Volatile RAM) Kingston&Webbench Kingston&Facebook RiData&Webbench RiData&Facebook

10. Evolved!! I/O stack optimization for smartphones Revisiting storage for smartphones

11. Elimination of JOJ(Journaling of Journal) • Journaling in SQLite • 6 Journaling modes • DELTE (Default before Android 4.0.4) • TRUNCATE(Default since Android 4.0.4) • PERSIST • MEMORY • WAL(Write-Ahead-Logging) • OFF

12. Elimination of JOJ • Journaling Mode : Delete • Delete journal when atomic transaction successfully processed (unlink, delete) • Journaling Mode : Truncate • Don’t delete journal even if a transaction completed, instead, truncate by zero (delete) • But both of delete & truncate need new allocation

13. Elimination of JOJ • Journaling Mode : Persist • Overwrite journal by zero (=zero-fill) • No need for reallocation, if journal has to be updated, reuse zero-filled journal • Journaling Mode : Memory • Keeping journal on memory • If application crashes entirely, no way to rollback • Fastest 000000000000000000000000000000000

14. Elimination of JOJ • Journaling Mode : WAL • Create a separate WAL file(.wal) • .wal is checkpointed every specified threshold • Journaling Mode : OFF • No journal • No guarantee atomic operation Checkpointed Checkpointed Checkpointed Checkpointed Database(.db) WAL(.wal)

15. Elimination of JOJ • Journaling in EXT4 • Overhead of journaling is negligible • Journal transaction is much bigger than SQLite • Journal transaction interval is much longer (e.g. 5sec) • But if in SQLite? • SQLite order fsync() command to commit journal to EXT4 • In experiment, a INSERT SQLite SQL issues 2 or more fsync() within 2ms • Moreover, each fsync() consists tiny chunkscontaining very few records • Causes very inefficiency from fsync()-> 200% Overhead

16. Elimination of JOJ • What fsync causes Red numbers denote data size(KB), red X represent write operation

17. Elimination of JOJ • Comparison along SQLite journaling mode 24KB of operation instruction size 3 fsync() calls 9 write operations

18. Elimination of JOJ • Comparison along SQLite journaling mode 16KB of operation instruction size No opening & unlinking of .db-journal 2 fsync() calls 8 write operations

19. Elimination of JOJ • Comparison along SQLite journaling mode 8KB of operation instruction size No opening & unlinking of .db-journal 3 fsync() calls 12 write operations -> Caused by zero-filling : Not adequate EXT4

20. Elimination of JOJ • Comparison along SQLite journaling mode 16KB of operation instruction size 1 fsync() call 2 write operations

21. Elimination of JOJ • Another filesystem for Android • Uses B+ tree • COW mechanism(Copy on Write) • Wandering tree problem Updating a node invokes other nodes to be updated • 1 fsync : 6 writes

22. Elimination of JOJ • Another filesystem for Android • Log structured • Merging chunks andcombine to segment • Size of a segment is128KB • fsync contains a command of flushing segment • Due to too big segment & flushing operationit reveals worst performance

23. Elimination of JOJ • Another filesystem for Android • To support enterpriselevel storage • But result has beenreversed • One fsync calls only one journal write • Minimum journal write is 1KBIn EXT4 : 4KB

24. Elimination of JOJ • Another filesystem for Android • Log structured • Not only supports merging data tosegments, but alsooperation that updatingsmall chunks to storage, which is not supported the other LFS (e.g. NILFS2) • So, it is relieved of suffering from updating tiny chunk

25. Elimination of JOJ • Seq, rnd write with fsync

26. Ref: http://www.lug.or.kr/m/bbs/view.php?bo_table=centos_book&wr_id=70&page=8 Elimination of JOJ • fsync, fdatasyncand noatime • fsync flushes metadata every operation • fdatasync doesn’t flush metadata until existing metadata is required to be flushed which caused by considerable metadata is to be journaled • noatime : Mount option • atime : Linux logs the time of last access • relatime : Updates when current modify or change time is expired, compared with last access time • noatime : Don’t log unless the file is written(modified) i.e. don’t log access time(Default Android mount option)

27. Elimination of JOJ • Evaluation of JOJelimination • F2FS is best, XFSis next • BTRFS & NILFS2gain benefit hardly Caused by COW: COW mechanism interference advantage of fdatasync that doesn’t flush metadata

28. Elimination of JOJ • Evaluation JOJ • VariantSQLite journalingmodes, filesystems • In update in DB onGalaxy S3, there isno journal filecreation(Difference betweenInsert/sec andUpdate/sec)

29. External journaling • Exploit Locality • Data IO seemsrandom • Journal IOlooks contiguous • External journaling • Put journal another block(=partition) • As a result, external journaling can exploitlocality to the maximum

30. Polling-based IO • Flash vs HDD • In legacy PC system,the size of I/O interruptis much bigger thana smartphone system • So, frequent contextswitches may be harmful • Actually, as shown table 1, polling I/O consumes more CPU but this is ignorable because of dominant power consumption from display and telecommunication elements

31. Polling-based IO • Power consumption in smartphone Power usage on Web browsing Power usage on E-Mail

32. Overall result • Combining all advances • EXT4 -> EXT4 advanced : about 2.4X • EXT4 -> F2FS baseline : about 2.2X • EXT4 -> F2FS advanced : about 4X

34. Any question?