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

2. Contents Intro Past work Elimination of JOJ External Journaling
Polling based I/O
Evaluation
Related Work & Conclusion
운이 좋게도 작년에 발표했던 Revisiting storage for smartphones와 매우 유사
참조 논문 역시 작년에 발표했던 내용..

3. Intro Android adopts DB Nevertheless..
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..
Nevertheless SQLite has poor performance

4. Intro Ext4 A default file system since LINUX kernel ver. 2.6.28
Ref:
Ext4
A default file system since LINUX kernel ver
Introduces journaling also due to improve reliability
Became default Android file system from ICS, ver
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
Btrfs : B-tree filesystem
Providing cloning mechanism which is suitable for VM, Block discard to improve wear leveling on SSD Trim
Online defragmentation, volume expansion or shrinkage, load balancing

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

6. Revisiting storage for smartphones
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. Revisiting storage for smartphones
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. Revisiting storage for smartphones
Past work
Revisiting storage for smartphones
Treat random write as sequential write
Lazy evaluation

9. Revisiting storage for smartphones
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
Kingston is really poor flash!!
Didn’t use real PCM in experiment, but simulated

10. Evolved!! Revisiting storage for smartphones
I/O stack optimization 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. Journaling Mode : Delete
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
delete : 텍스트 파일과 디렉토리 엔트리 모두 지움
truncate : 텍스트 파일만 지움 (엔트리 유지)

13. Journaling Mode : Persist
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
Persist : 텍스트 파일을 0으로 채움
reallocation cost >> write cost인 경우 사용(임베디드 또는 특수 플랫폼)

14. Elimination of JOJ Journaling Mode : WAL Journaling Mode : OFF
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)
WAL : 저널을 위한 파일이 차곡차곡 쌓이므로 sequential한 성향을 보이게 됨.
추가 저장공간 필요

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 chunks containing 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
X의 개수와 크기에 대해 설명

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

18. Comparison along SQLite journaling mode
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. Comparison along SQLite journaling mode
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. Comparison along SQLite journaling mode
Elimination of JOJ
Comparison along SQLite journaling mode
16KB of operation instruction size
1 fsync() call
2 write operations

21. Another filesystem for Android
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. Another filesystem for Android
Elimination of JOJ
Another filesystem for Android
Log structured
Merging chunks and combine to segment
Size of a segment is 128KB
fsync contains a command of flushing segment
Due to too big segment & flushing operation it reveals worst performance

23. Another filesystem for Android
Elimination of JOJ
Another filesystem for Android
To support enterprise level storage
But result has been reversed
One fsync calls only one journal write
Minimum journal write is 1KB In EXT4 : 4KB

24. Another filesystem for Android
Elimination of JOJ
Another filesystem for Android
Log structured
Not only supports merging data to segments, but also operation that updating small 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. fsync, fdatasync and noatime
Elimination of JOJ
Ref: bo_table=centos_book&wr_id=70&page=8
fsync, fdatasync and 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. Evaluation of JOJ elimination
Elimination of JOJ
Evaluation of JOJ elimination
F2FS is best, XFS is next
BTRFS & NILFS2 gain benefit hardly
Caused by COW:
COW mechanism
interference advantage
of fdatasync that
doesn’t flush metadata

28. Elimination of JOJ Evaluation JOJ
Variant SQLite journaling modes, filesystems
In update in DB on Galaxy S3, there is no journal file creation (Difference between Insert/sec and Update/sec)

29. External journaling Exploit Locality Data IO seems random
Journal IO looks contiguous
External journaling
Put journal another block(=partition)
As a result, external journaling can exploit locality to the maximum

30. Polling-based IO Flash vs HDD
In legacy PC system, the size of I/O interrupt is much bigger than a smartphone system
So, frequent context switches 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
Context switch는 Log-scale임에 주의

31. Power consumption in smartphone
Polling-based IO
Power consumption in smartphone
Power usage on
Power usage on Web browsing
단, LCD가 TFT가 아닌 LED라 전력 소모가 적었음
TFT였다면 꽤나 큰 차이를 보였을 것임

32. Combining all advances
Overall result
Combining all advances
EXT4 -> EXT4 advanced : about 2.4X
EXT4 -> F2FS baseline : about 2.2X
EXT4 -> F2FS advanced : about 4X
단, LCD가 TFT가 아닌 LED라 전력 소모가 적었음
TFT였다면 꽤나 큰 차이를 보였을 것임

34. Any question?