Memory-Centric Data Storage for Mobile Systems

Jinglei Ren, Mike Liang, Yongwei Wu, Thomas Moscibroda Two things you may dislike most about your smartphone…

Battery drain Low responsiveness 1 But do you know… What Is an app doing Behind you?!

Twitter’s fsync() system calls

(sec.) Storage impairs both energy efficiency and responsiveness! 2 Traditional Design

DB Page Cache (memory) FS flush/5s fsync()

(flash)

3 Traditional Design Programmers’ dilemma

malloc() malloc() malloc() POSIX malloc() malloc() The fsync() function malloc() malloc() malloc() malloc() shall not return until the malloc() malloc() system has completed malloc() that action or until an malloc() malloc() error is detected. Old-fashioned design… 4 Solution Overview Flash storage vs. DRAM residence: Can we find a sweet spot between the two?

DB Page Store (memory) FS checkpoint

(flash)

5 Insight I Storing app data on smartphone memory is not as risky as it sounds. • A smartphone is self-contained,i.e., battery- backed. • System-wise crash is rare. Our survey: only 6% users experienced more than once per month. • Our case studies: 54 out of top 62 free apps in Google Play are vulnerable to local data loss.

6 Insight I

Buddy, I am skiving off USENIX ATC. Storing app data on smartphoneDon’t tell my boss! memory is not as risky as it sounds. What information do •weA collectsmartphone? is self-contained,i.e., battery- …Thisbacked. can include your name, profile photo, •Pins,System comments,-wise likes,crash is rare. OurBuddy,survey I am skiving: offo nly 6% email address…, and USENIX ATC. Don’t tell users experienced more thanmy boss!once per month. any other information •youOur providecase us.studies: 54 out of top 62 free apps in Google Play are vulnerable to local data loss.

7 System Design: Mechanism Versioned Cache Transaction (VCT) • Introducing transactions to OS page cache • Basic life cycle: – Open a VCT for certain files – Perform Copy-on-Write for dirty pages – Coalesce writes on these new versions of pages – Close a VCT according to our policy • VCTs of different apps are independent, for optimization purpose.

8 Insight II Memory capacity on smartphones is ample enough for app data storage.

8192 4096 Samsung Galaxy S6 Samsung Note 3 ) 2048 Samsung Note 2

B

M

(

1024 Samsung S3

y

t HTC Sensation

i

c 512 HTC Desire Nexus One

a

p a 256 Samsung B7320 HTC Hero

C HTC Dream

M 128 Nokia N97 A Samsung F700

R

D 64 Nokia N70 Samsung i600 32 Samsung i530 16 2004 2006 2008 2010 2012 2014 Year

9 System Design: Mechanism MobiFS components

10 Insight III Reducing the amount of data flushed to flash is a key to save app energy. • Our measurement: the overall read energy is only 6.3% of write energy • The amount of data to flush, rather than the number of batches, is the dominant factor. Our measurement: writing 40 MB data in batches ranging from 4 to 40 MB results in a net energy consumption difference within 1.5%. 11 Insight V

100

90

% 80

g

n

i

v

a 70 S Facebook: 0-11.4MB 60 Twitter: 0-156.2MB GoogleMaps: 0-175.8MB Browser: 0-9.5MB 50 0 20 40 60 80 100 Staleness (Unified) App I/O patterns suggest adaptive policies to balance the staleness-energy tradeoff, which can be achieved in a quantitative way.

12 System Design: Policy Tradeoff Point Location • New metric for energy efficiency: the e curve e = coalesced data size / staleness • Principle: reduce data staleness unless the otherwise increases energy efficiency. • Peak detection algorithm: – Detection window – Incremental linear regression – Threshold for gradient (not necessarily 0)

13 System Design: Policy • Tradeoffs between three objectives: data staleness, energy efficiency and app responsiveness. • The tradeoff point location algorithm only closes a transaction, making it ready to be checkpointed.

Responsiveness-oriented policy: when to ckpt.

14 Insight IV Relaxing the timing of flushes is a key to app responsiveness. • Prior work has shown the implication of fsync() [Jeong et al. ATC’13, Lee et al. EMSOFT’12] and background flushing [Kim et al. FAST’12, Nguyen et al. UbiComp’14]. • What is the right timing for flushing? Our measurement: when the device is idle. Standby is not good timing – leading to 129% extra energy consumption 15 System Design: Policy Interval Prediction • Rationale: predict according to history • Last min policy – Pessimistic in prediction, with least conflicts – Limiting flush data size • Last average policy – Incurring more conflicts – Enabling larger flush data size

16 System Design: Policy Interval Prediction • To learn two modes in user interaction

17 Implementation and Evaluation A working prototype • Android 4.1 (Linux 3.0.31) • Integrated with either Ext4 (journaling data) or Btrfs (COW) Experiments • Traces from real users • Benchmarks + real apps (monkeyrunner) • Use real devices: Samsung Galaxy Premier I9260 (dual-core 1.5 GHz CPU, 1 GB RAM);

18 Evaluation: Energy

100 100 80 80

% % 60 60

g g

n n

i i

v v

a 40 a 40 S Ideal S Ideal 20 Ext4 20 Ext4 MobiFS MobiFS 0 0 0 1 2 3 4 5 6 0 5 10 15 20 25 30 35 40 Facebook: Staleness (MB) Twitter: Staleness (MB) With ten most popular apps (by geo. mean): • MobiFS reduces the amount of flush data by 53.0% compared to Ext4.

19 Evaluation: Energy • Three representatives of real apps: Browser (low freq. of fsync), Facebook (middle freq. of fsync), Twitter (high freq. of fsync).

100

)

J 80

(

y 60

g

r

e 40

n

E 20 0 Browser Facebook Twitter

Ext4 MobiFS • On average, device energy consumption is reduced by 35.8% compared to Ext4. 20 Evaluation: Responsiveness

1000 16384

)

s / 4096

B 100

M

( 1024

t

S

u

P

p 10 256

O

h

I g 64

u

o r 1 16

h T 4 0.1 1 Seq.: Write Read Rand: Write Read

Ext4 MobiFS Ext4 MobiFS

• On average, 18.8× filesystem I/O throughput.

21 Evaluation: Responsiveness

) 16384

S

P

T 4096

(

.

c 1024

e

S

256

r

e

p 64

.

s

n 16

a

r

T 4 1 Insert Update Delete

Ext4 MobiFS • On average, 11.2× database transaction throughput. 22 Evaluation: Responsiveness

50 40

)

s

( 30

e

m i 20

T 10 0 Browser Facebook Twitter

Ext4 MobiFS • On average, user operation delay is reduced by 51.6%. 23 Related Work • Decouple of durability and consistency xsyncfs [OSDI’06], OptFS [SOSP’13], Blizzard [NSDI’14], TxCache [OSDI’10], etc.: different domains; static durability guarantee (e.g., up to x seconds of data loss). MobiFS: transactions in OS page cache; adaptive tradeoff for different mobile apps/users. • Energy optimizations SmartStorage [UbiComp’13]: read/write ratio; 6% ~ 9% slowdown for energy saving Coop-I/O [OSDI’02]: deferrable requests MobiFS: changed design rationale; best performance 24 Conclusion • We propose a memory-centric storage, based on our new insights in the mobile system design. • We trade off data durability for energy efficiency and app responsiveness, in a quantitative manner. • We introduce transactions to the OS page cache and implement MobiFS, to support the tradeoff transparently. • We achieve: (1) over one order of magnitude improvement in IO performance; (2) over 1/2 and 1/3 reduction in energy consumption and operation delay, respectively.

25 Thank you! [email protected]

26