I/O Stack Optimization for Smartphones Sooman Jeong1, Kisung Lee2,*, Seongjin Lee1, Seoungbum Son2,*, and Youjip Won1 1 Hanyang University, Seoul, Korea 2Samsung Electronics, Suwon, Korea Abstract ing devices for a variety of applications, including so- The Android I/O stack consists of elaborate and mature cial network services, games, cameras, camcorders, mp3 components (SQLite, the EXT4 filesystem, interrupt- players, and web browsers. driven I/O, and NAND-based storage) whose integrated The application performance of a smartphone is not behavior is not well-orchestrated, which leaves a sub- governed by the speed of its airlink, e.g., Wi-Fi, but stantial room for an improvement. We overhauled the rather by the storage performance, which is currently uti- block I/O behavior of five filesystems (EXT4, XFS, lized in a quite inefficient manner [11]. Furthermore, BTRFS, NILFS, and F2FS) under each of the five dif- one of the main sources of this inefficiency is an ex- ferent journaling modes of SQLite. We found that the cessive I/O activity caused by uncoordinated interac- most significant inefficiency originates from the fact that tions between EXT4 journaling and SQLite journaling filesystem journals the database journaling activity; we [14]. Despite its significant implications for the overall refer to this as the JOJ (Journaling of Journal) anomaly. smartphone performance, the I/O subsystem behavior of The JOJ overhead compounds in EXT4 when the bulky smartphones has not been studied nearly as thoroughly as EXT4 journaling activity is triggered by an fsync() call those in enterprise servers [26, 23], web servers [4, 10], from SQLite. We propose (i) the elimination of unnec- OLTP servers [15], and desktop PCs [34, 8]. essary metadata journaling for the filesystem, (ii) exter- In this work, we present extensive measurement re- nal journaling and (iii) polling-based I/O to improve the sults to understand Android’s I/O behavior and propose I/O performance, primarily to improve the efficiency of techniques to optimize the individual layers so that the filesystem journaling in the SQLite environment. We ex- overall Android I/O stack behaves much more efficiently amined the performance trade-offs for each combination when the layers are integrated. The Android I/O stack of the five database journaling modes, five filesystems is a collection of elaborate and mature software layers and three optimization techniques. When we applied (SQLite, EXT4, the interrupt-driven I/O of the Linux ker- three optimization techniques in existing Android I/O nel, and NAND-based storage), each of which has gone stack, the SQLite performance (inserts/sec) improved by through several years of development and refinement. 130%. With the F2FS filesystem, WAL journaling mode When the layers are integrated, the resulting I/O behav- (SQLite), and the combination of our optimization ef- ior is not well-orchestrated and leaves a substantial room forts, we improved the SQLite performance (inserts/sec) for an improvement. We overhaul the I/O stack of the by 300%, from 39 ins/sec to 157 ins/sec, compared to the Android platform from DBMS to a storage device and stock Android I/O stack. propose several techniques to improve the performance. Our contributions are as follows: 1 Introduction Starting from EXT4, we performed an extensive Smart devices, e.g., smartphones, tablets, and smart TVs, • performance study of five filesystems (BTRFS, XFS, have become mainstream computing devices and are NILFS, and F2FS [1]) in one of the most recent Android- quickly replacing their predecessor, PCs. Smartphones based smartphones and examined how they interact with and tablets have become the dominant source of DRAM each journaling mode of SQLite. We found that SQLite consumption [17] and account for 45% of Internet web journaling interacts with the EXT4 journaling layer in browsing [18]. They are becoming the personal comput- an unexpected way and, the EXT4 filesystem stresses * This work was done while the author was a graduate student at the storage device in a way that was rarely seen before. Hanyang University. USENIX Association 2013 USENIX Annual Technical Conference (USENIX ATC ’13) 309 We found that recently introduced F2FS can be a good "115"%$ &8&6 5'(828 97'0&7 56&7 !!! remedy for Journaling of Journal anomaly which current 7''8I stock Android I/O stack suffers from. "#$ Q"R ()'0 1234& %&&'( !!! %S Examining five journal modes of SQLite, we found "%TR • 9" %# that Write-Ahead-Logging mode(WAL) yields the best @8& A2 !!! 5'7&A B3C# 1788'( &278'( A''8 H64&E76)3 performance since it generates smallest amount of the 7&2'B&7 7&2'B&7 synchronous random writes amongst all SQLite journal !!! 22& I76P)8& 8&6 "()7')$ modes. 9'23&B2& )8 28'(())8 We propose the use of external journaling, in which the D(8&7("E&##5E&F8&7( G )27) &F8&7()8 • filesystem journal is maintained in a separate storage de- Figure 1: Android Architecture and Storage Partition vice to explicitly preserve the access locality induced by the filesystem journal file access. This approach enables braries used extensively by various system components the FTL layer of the NAND storage to more effectively and applications; some of the most widely used libraries exploit the locality of the incoming I/O stream so that it are SQLite, libc, and the media libraries. The Linux can reduce the NAND flash management overhead, e.g., kernel provides core services, such as memory manage- garbage collection in page mapping and the log block ment, process management, security, networking, and a merge operation in hybrid mapping. driver model. Android uses the Dalvik virtual machine We found that SQLite triggers a significant amount • (VM) with just-in-time compilation to run .dex (Dalvik of synchronous random write traffic when it commits Executable) files, and an application runs on top of the its journal file to the filesystem, a significant fraction of Dalvik VM. which is not required. We tuned SQLite to eliminate this We define the Android I/O stack as a set of software random write I/O by employing fdatasync() in place and hardware layers used by applications for persistent of fsync(). data management. The I/O stack of the Android plat- NAND-based storage is sufficiently fast, and state-of- • form consists of the DBMS, filesystem, block device the-art smartphones are equipped with a sufficient num- driver, and NAND flash based storage device. SQLite ber of CPU cores. We developed a polling-based I/O sys- and EXT4 are the default DBMS and filesystem, respec- tem for Android storage devices and studied its effective- tively. The Android platform uses interrupt driven I/O ness. with a CFQ I/O scheduling scheme. The eMMC and SD Combining these optimization efforts with the opti- card are used as internal and external storage devices, re- mal choices for the filesystem and database journaling spectively. mode of SQLite (i.e., by F2FS, WAL journaling mode Most Android applications use SQLite to manage data in SQLite, using external journaling, eliminating unnec- in a persistent manner. SQLite interacts with the under- essary metadata commits, and polling-based I/O), we lying filesystems through the usual system calls, such as achieved a 300% improvement in the SQLite perfor- open(), unlink(), write(), and fsync(). SQLite mance (inserts/sec) compared to the stock Android plat- uses journaling for recovery. It records rollback informa- form. tion at .db-journal file. The database file and journal The remainder of the paper is organized as follows: file are frequently synchronized with the storage device Section 2 presents the background. The I/O characteris- using fsync(). tics of Android is briefly described in Section 3, and the current Android I/O stack is examined in Section 4. Sec- Since the release of Android 4.0.4 (Ice Cream Sand- tion 5 explores various filesystem choices for Android. wich), Android only uses EXT4 to manage its internal Section 6 provides optimization techniques for the An- storage, eMMC. droid I/O stack. Section 7 presents the results of our in- 2.2 AndroStep: Android Storage Analyzer tegration of the proposed schemes. Section 8 describes We use Androstep [9] to collect, analyze and replay the other works related to this study. Our conclusions are trace in this study. AndroStep is a collection of tools de- presented in Section 9. veloped for analyzing the storage stack behavior of An- 1 2 2 Background droid. It consists of Mobibench , MOST , and Mobi- gen3. Mobibench (mobile benchmark) is an I/O work- 2.1 Android I/O Stack load generator which is specifically designed for An- Google Android is an open-source Linux-based operat- ing system designed for mobile devices. Figure 1 illus- 1https://github.com/ESOS-Lab/Mobibench, available at Google playstore trates the architecture of Android. Android applications 2https://github.com/ ESOS-Lab/MOST are written in Java and packaged as .apk (Android Ap- 3https://github.com/ESOS-Lab/Mobibench/tree/master/ plication Package) files. Android provides a set of li- MobiGen 2 310 2013 USENIX Annual Technical Conference (USENIX ATC ’13) USENIX Association SQLite(journal) Others Metadata Journal Data Synchronous Buffered SQLite(db) Resource Executable Multimedia 229 4898 22 1033 100 5704 1558 80 100 229 2561 20 504 80 100 60 80 60 60 40 40 40 % of total 20 20 % of total 20 % of total 0 0 0 R W R W R W R W W W Facebook Twitter Facebook Twitter Facebook Twitter (a) File Types (b) Block Types (c) I/O Modes Sequential Random <=16KB <=256KB WiFi(sdio) Others <=4KB <=64KB >256KB eMMC Acc/Gyro Touch GPU 100 2MB 33MB 0.7MB 4MB 229 5705 22 1559 80 100 100 80 80 60 60 60 40 40 40 20 % of total 20 % of total 20 % of total 0 0 0 R W R W R W R W IRQs IRQs Facebook Twitter Facebook Twitter Facebook Twitter (d) Locality (e) I/O Size (f) IRQs Figure 2: I/O distribution of file types, block types, I/O modes, randomness, and I/O size.