Implementing Persistent File Cache onAndroid Operating System

Prakhar Panwaria, Prashant Saxena, Robin Paul PrakashComputer Sciences Department

University of Wisconsin-Madison

{prakhar, prashant, rprakash}@cs.wisc.edu

Abstract

In conventional systems, memory is treated as a non-persistent storage. Because the contents of memoryare volatile, changes to the data stored in memory areperiodically written back to the disk. But some ap-plications, which require higher reliability, explicitlyflushes the file cache to disk at a much higher rate,thus affecting performance and energy consumption.This memory’s perceived unreliability forces a trade-off between performance and reliability. In batterybacked systems like mobile phones, the chances ofunexpected power failures are much lesser when com-pared to conventional systems, which implies thatdata in memory is likely to be safe for a much longerduration. We leverage this idea to develop a modelwhich modifies the file cache to behave as a persistentfile cache, and hence increase system performanceand power efficiency. Since data is kept in memoryfor a longer duration, it is more prone to corruptiondue to kernel bugs like buffer overflows. We proposetwo mechanisms - write protecting pages and use oftranscendent memory, to address this issue. We alsopresent analysis of the performance and power im-provements of our system.

1 Introduction

In the modern storage hierarchy, I/O devicessuch as hard disk drives are considered to be re-liable storage medium, whereas random-accessmemory (RAM), being volatile, is viewed as un-safe to store any data for a long duration. How-ever, the access time of memory is significantlylesser than that of disks. Hence, to increase theperformance, systems try to read bulk of datafrom the I/O device to the cache and then readit directly from the cache rather than reading

it multiple times from disks. Similarly, data-writes to disk are also buffered in caches andare flushed to disk in larger blocks (to reducedisk seek time) and at larger intervals (to re-duce number of disk accesses). Applicationsthat desire higher reliability flush data to thedisk explicitly at much higher rates, in order tominimize data loss in case of unexpected powerfailures or system crashes. Though this leadsto better safeguarding of data, it increases thenumber of disk accesses, thereby decreasing theoverall performance of the system.

It is intuitive to believe that if a better mecha-nism is provided to protect data in memory, thencontents in memory can be treated as persistentand such reliability induced flushes to disk canbe avoided. In battery backed systems like mo-bile phones, the chances of unexpected powerfailures are much lesser when compared to con-ventional systems, which implies that data inmemory is likely to be safe for a much longer du-ration. A robust protection mechanism on topof persistent memory on such devices can deliversignificant performance boost. We leverage thisidea to develop a model for mobile platform op-erating system which modifies the file cache tobehave as a persistent file cache, and hence in-crease system performance and power efficiency.

With these ideas in mind, our goal is to achieveperformance of main memory with reliability ofdisk for mobile systems. The major parts of thedesign are:

1. Overriding flush requests from the applica-tion and managing interval at which data is

1

written to disk.

2. Implementation of mechanism to protectdata in memory.

3. Securing contents of the memory in case ofa system crash/reboot.

We present the design and implementation ofour prototype on the Linux-based operating sys-tem from Google - Android [16]. Since hand-held devices store permanent data in sdcardsinstead of spinning disks, we evaluate our sys-tem performance on sdcards only. However, forthe sake of generality, we refer to disks as per-manent media for storage in rest of the paper.Performance evaluation clearly shows merits ofour approach. For write intensive workloads, weget performance gains up to 143% (in emulator)and 155% (in hardware) over standard Androidkernel.

The rest of the paper is divided as follows. InSection 2, we discuss the research work that hasbeen done around making file system more reli-able, while improving its performance. In Sec-tion 3, we describe how we can make main mem-ory behave as persistent storage. We also dis-cuss mechanisms for in-memory data protectionfrom system crashes and kernel bugs. In Sec-tion 4, we present the evaluation of our model,and show how modifying file cache parametersand avoiding flushing of data can enhance sys-tem performance and decrease power consump-tion. We present our conclusions in Section 5.

2 Related Work

In past, multiple attempts to model reliablemain memory for persistent storage have beenproposed [1,2,3,4]. Mnemosyne [1] deals withstorage class persistent (SCM) memory. The re-search builds upon the fact that storage classmemory provides data persistence inherentlyand hence proposes mechanisms to expose SCMdirectly to the application layer. There is a simi-lar study around using NVRAM [2] (non-volatileRAM) along with client cache to improve filesystem reliability (data persists longer) and per-

formance (less write traffic). Software PersistentMemory [3] talks about securing in-memory con-tent by modifying data structure managementschemes of particular language (C in their case).

Phoenix [4] attempts to make all permanent filesreliable while in main memory. It keeps two ver-sions of an in-memory file system. One of theseversions is kept write-protected, the other ver-sion is unprotected and evolves from the writeprotected one via copy-on-write. At periodiccheck-points, the system write-protects the un-protected version and deletes obsolete pages inthe original version.

Conquest [5] leverages the declining cost of per-sistent RAM technologies like battery-backedRAMs to implement a disk/persistent-RAM hy-brid file system that holds small files in the bat-tery backed persistent RAM and large files indisks. As a new file systems with separate datapaths for in-core and on-disk storage was de-signed, changes were needed in the operatingsystem as well. The performance tests usingbenchmarks shows a performance improvementof 43% to 97% over disk- based file systems.

None of the approaches to persistent storagedescribed above are directly applicable to ourmodel. Mnemosyne approach cannot be portedon Android based systems due to lack of SCMin mobile hardware. Instead, our approach fo-cuses on providing standard disk based persis-tent memory. Software persistent memory haslimited use in Android based systems since ap-plication memory management is mostly donetransparently by Dalvik virtual machine. Wepropose modification at kernel level, which op-erates below the Dalvik virtual machine to pro-vide support for persistent memory. Using hy-brid file system entails major change in Androidoperating system, and hence is out of scope ofour work.

What is more relevant is protecting the mem-ory from operating system crashes and overwrit-ing of application data through unauthorized ac-cesses. Rio file cache [6,7] tries to address thisissue by forcing all processes including the ker-nel to access memory through the virtual mem-

2

ory mechanism, thereby avoiding dangling ker-nel pointers overwriting application data in theevent of a system crash. However, Rio File cacheimplementation as defined in [6] uses warm re-boot, which writes file cache data to disk duringreboot. Unfortunately, warm reboot relies onseveral specific hardware features, such as a re-set button that does not erase memory, and isnot applicable to most class of hardware used inhandheld devices.

Techniques like Recovery Box [8], keeps backupcopies to enable recovery of the system once itcrashes. As the aim of our recovery mechanismis not to prevent applications from saving cor-rupted data, but to recover unsaved data in theevent of a crash, we do not need a recovery mech-anism based on checkpointing as we are able tosave the entire memory contents before a reboot.Our work is inspired by SafeSync [7] approach,which is a software based technique that requiresno hardware support. It writes dirty file cachedata reliably to the disk during the last stage ofa crash.

Our approach to memory protection primarilyuses two mechanisms - write-protecting pagesto avoid illegal accesses via corrupt pointers,and making a copy of dirty data in transcendentmemory [9,10], which is not directly accessibleby kernel. These two mechanisms provide thenecessary protection to secure the contents ofmemory. By using zcache [11,12] to compressthe pages, transcendent memory provides effi-cient storage of duplicate pages without causingtoo much memory overhead.

3 Design and implementation of a Re-liable File cache

This section describes how we modified the filecache implementation in Android operating sys-tem to behave as a persistent file cache. We alsodescribe mechanisms to protect in-memory datafrom system crashes and kernel bugs.

3.1 Persistent File Cache

As discussed in previous sections, reading andwriting data off the memory is relatively fastwhen compared to I/O from disks. Hence, ouraim is to retain the data in memory for longerduration and serve subsequent requests fromcache. In conventional Android kernel, data mi-gration from memory to disk can happen in twoscenarios - a) Explicit transfer, where an ap-plication uses system calls to flush the data tothe disk, or b) Implicit transfer, where OS pe-riodically flushes the data from buffers to disk.In Android OS, implicit transfer happens every30 seconds. Implicit transfer guards the userfrom losing data in case of power failure or sys-tem crash. In case of crash, only data betweenthe implicit transfer checkpoints is lost. Sincethis window (30 seconds) is relatively small, verysmall amount of data is at risk of being lost.

In following subsections, we briefly define filesynchronization mechanism adopted in AndroidLinux kernel and highlight major changes toachieve our goal of retaining data in memory.

3.1.1 File synchronization mechanism inAndroid Linux kernel

Both implicit and explicit transfers are per-formed using three system calls as defined be-low:

• sync() - Allows a process to flush all dirtypages to disk

• fsync() - Allows a process to flush all pagesthat belong to a specific open file to disk

• fdatasync() - Very similar to fsync(), butdoesn’t flush the inode block of the file

The service routine sys sync() of the sync() sys-tem call invokes a series of auxiliary functions-wakeup bdflush(), sync inodes(), sync supers()and sync filesystems().

wakeup bdflush() starts a pdflush kernel thread,which flushes to disk all dirty pages contained inthe page cache.The sync inodes() function scans

3

the list of superblocks looking for dirty inodes tobe flushed. The function scans the superblocksof all currently mounted filesystems; for each su-perblock containing dirty inodes it first invokessync sb inodes() to flush the corresponding dirtypages, then invokes sync blockdev() to explic-itly flush the dirty buffer pages owned by theblock device that includes the superblock. Thesync blockdev() function makes sure that the up-dates made by sync sb inodes() are effectivelywritten to disk. The sync supers() functionwrites the dirty superblocks to disk, if neces-sary, by using the proper write super superblockoperations. Finally, the sync filesystems() ex-ecutes the sync fssuperblock() method for allwritable file systems.

The fsync() system call forces the kernel to writeto disk all dirty buffers that belong to the filespecified by the fd file descriptor parameter (in-cluding the buffer containing its inode, if neces-sary). The corresponding service routine derivesthe address of the file object and then invokesthe fsync() method. Usually, this method endsup invoking the writeback single inode() func-tion to write back both the dirty pages associ-ated with the selected inode and the inode it-self. The fdatasync() system call is very similarto fsync(), but writes to disk only the buffersthat contain the file’s data, not those that con-tain inode information. Because Linux 2.6 doesnot have a specific file method for fdatasync(),this system call uses the fsync() method and isthus identical to fsync().

3.1.2 Modifications to file synchroniza-tion mechanism

In our implementation, we intercept sync(),fsync() and fdatasync() system calls and pre-vent them from flushing data back to the disk.To achieve this functionality, we use a flag basedmechanism to switch between standard modeand custom mode of operation. We definefsync enabled flag which is set to false for allexplicit synchronization calls. To allow OS towrite data back at implicit checkpoints defined

previously, we reset the flag to true to allow nor-mal mode of operation. The dual mode of op-eration also gives the user flexibility to switchbetween the two data synchronization modes.

Linux usually writes data out of the page cacheusing a process called pdflush. The behaviourof this multithreaded process is controlled bya series of parameters defined in /proc/sys/vm.These parameters are accessed and processes infile page-writeback.c. Few important param-eters modified in our implementation are de-scribed below:

• dirty writeback centisecs (default 500): Inhundredths of a second, this is how oftenpdflush wakes up to write data to disk.

• dirty expire centiseconds (default 3000): Inhundredths of a second, this parameter de-fines for how long data can be in the pagecache before it’s considered expired andmust be written at the next opportunity.Note that this default calculates to 30 sec-onds.

• dirty background ratio (default 10): Maxi-mum percentage of active pages that canbe filled with dirty pages before pdflush be-gins to write them.

To increase the implicit writeback time, wemodify dirty expire centiseconds to increase thedirty pages writeback time to 2 minutes un-der normal load condition. We also mod-ify dirty writeback centisecs to 1 minute anddirty background ratio to 50 to initiate pageflush in between checkpoint duration to handlesudden spikes in workload.

The increase in dirty writeback time from 30seconds to 2 minutes brings along a consider-able risk of data loss in case of system crashbetween the checkpoints. To mitigate this prob-lem, we modify kernel panic call stack to callsync() function before rebooting the system. Aswe show in the evaluation section, this improvesthe performance of reads and writes by a factorof 1.4 over conventional Linux kernel.

Overriding application requests to sync data

4

brings along a considerable risk of data lossin case of system crash between implicit-synccheckpoints. There are different solutions tothis problem. One approach is to do a warmreboot, as used in Rio file cache[6], where oncethe system recovers from a crash, data is readfrom the file cache and then synced to the disk.Other approach is to write dirty pages sequen-tially to a separate part of the disk before re-booting and maintain data structures to tracklocation of these pages in disk. Once the systemhas rebooted, this dump of dirty pages is readand synced to the disk. But, for our usecase, weconsider a simplified approach, which is to mod-ify kernel panic call stack to call sync() functionbefore rebooting the system.

3.2 Memory Protection

When file data is forced to remain in volatilememory and calls to fsync() are overridden,there is an increased responsibility on the oper-ating system to safeguard this data. The majorsource of concern would be unexpected powerfailures which would lead to loss of all datastored in the volatile memory. But, in batterybacked devices like mobile phones, since thereare no unexpected power failures, this is nota source of concern for our system. We flushthe dirty pages in the file cache to disk at regu-lar intervals (currently 2 minutes) to reduce thedata loss in case the user decides to pull thebattery out. To avoid data losses in case thebattery runs out of charge, we revert to defaultbehaviour of fsync() and flushing dirty pages todisk every 30 seconds, once the battery chargeis below a certain threshold.

Though data loss due to power failure is not amajor source of concern, the corruption of datakept in memory is a serious issue that needs tobe dealt with. As kernel bugs like buffer over-flows are not very uncommon [13, 14, 15], thedecision to keep data in memory without takingregular backups would make it more prone tocorrupt pointer accesses from the kernel. There-fore, a system which risks its data by keeping itin the file cache should also provide a mechanism

to prevent the pages from getting corruptedthrough illegal accesses. A brief description offile permissions, the Linux page cache and howfile-backed pages are handled in Linux follows,before describing our mechanisms to provide ex-tra protection to the contents of the file cache.

When user invokes the system call sys open()to open a file, the kernel checks the file permis-sions and confirms whether the user is autho-rized to open the file in the mode requested bythe user. The file system keeps track of the per-missions with which each file was opened, andany subsequent unauthorized calls to sys read()or sys write() are blocked by the file system afterchecking with these permissions. As this mech-anism is implemented at the file system level, itprotects the file data only from illegal accessesthrough the file system calls. However, any cor-rupt pointer in the kernel which points to the filedata page can still corrupt the file data. There-fore a mechanism has to devised which coulddeal with protection at the page level.

Linux splits the address space of any process intotwo regions - the user space and the kernel space.While the user space is different for each processand changes with context switches, the kerneladdress space is shared among all the processes.When a request for loading a page to memoryis handled by the system calls, sys read() orsys write(), the page is brought to main mem-ory and mapped to a virtual address in the ker-nel address space. Needless to say, the page isaccessible only while running in Kernel Modeand not from the User Mode. Therefore, theextra protection that we implement deals withaccesses from the kernel space and not from theuser space.

We propose two different mechanisms throughwhich an increased protection from corrupt ker-nel pointers can be achieved. The first methodwrite-protects all file-backed pages in the filecache by changing the protection bits in the pagetable entry, and removes the write protectiononly when data is to be copied to the file pagefrom the application buffer. The second pro-vides protection by maintaining the file-backed

5

pages in transcendent memory, which is not di-rectly addressable by kernel.

3.2.1 Write Protection in Page Table en-tries

A common source of kernel bugs is buffer over-flows which would result in illegal pointer ac-cesses to pages from within the kernel. In or-der to prevent such accesses and allow accessto file-backed pages only via file system callslike sys write() and sys read(), a mechanismwas needed which would check access rights oneach and every access to the page. In mostmodern systems that support virtual memory,all accesses to the file pages by the kernel arethrough virtual addresses. Linux has a three-level page table with top level Page Global Di-rectory (PGD), the second level Page MiddleDirectory (PMD) and the final level contain-ing the actual Page Table Entries (PTE) whichstores the physical address of the page framebeing referenced. Apart from the physical ad-dress of the page, the PTE also stores protectionflags that have been set on the page. The pro-tection flags, unlike the ones maintained by thefile system, are checked by the virtual-physicaladdress translation hardware, on each access tothe page. Therefore, write protecting the pagesat the PTE level would protect the page fromany illegal accesses to the page. In case of legalwrites (i.e. sys write() function calls), the writeprotection is removed just before copying datafrom the application buffer into the file page,and restored after copying. This would reducethe window of vulnerability by a great extent.

The following is the code used to write-protecta particular page. The function page address()returns the address of the page we are trying towrite-protect. This address (with appropriatemasks) is used as index into the PGD, PMDand PTE tables.

unsigned long addr;

pgd_t* pgd;

pud_t *pud;

pmd_t *pmd;

pte_t *ptep, pte;

addr = (unsigned long)page_address(page);

pgd = pgd_offset_k(addr);

if (!pgd_none(*pgd))

{

pmd = pmd_offset(pud, addr);

if (!pmd_none(*pmd))

{

ptep = pte_offset_map(pmd, addr);

pte = pte_wrprotect(*ptep);

set_pte_at(&init_mm, addr, ptep, pte);

flush_tlb_kernel_page(addr);

}

}

The function pte wrprotect() is used to set thewrite-protect bit of the protection flags main-tained in the page table entry. Similarly, forremoving write protection before copying datafrom the application buffer to the pte mkwrite()function is used to remove the write-protect bitfrom the page table entry. The set pte at() func-tion writes back the page table entry to the lo-cation pointed to by ptep. Finally, the virtualto physical address translation that is cached inthe processor TLB is flushed, so that the nextaccess to the page causes the translation mech-anism to access the page table so that changesin permission are reflected from the very nextaccess to the page.

It is important to note that the extra protectionimplemented here is applicable only for pagesthat are backed by files, and not for any of theanonymous pages that the kernel would have al-located. This is because, unlike the system callsto file backed pages, there is no channelized wayin which anonymous pages are accessed.

3.2.2 Using Transcendent Memory

Our second approach for protection of applica-tion file data from kernel bugs is to put file-backed pages in a protected area which is notaddressable by the kernel. We found that wecould leverage transcendent memory [9,10] (as

6

Figure 1: Transcendent Memory

Figure 2: Transcendent Memory: Default con-figuration

Figure 3: Transcendent Memory: Proposedconfiguration

shown in Figure 1) for our purpose, as it is apart of memory which is not directly address-able by kernel and can be accessed only througha narrow, well-defined, but a quirky interfacecalled ’cleancache’.

Linux 3.0 kernel started supporting clean-

cache (as an optional feature), whichprovides an interface to transcendentmemory, with simple calls like clean-cache get page(), cleancache put page() andcleancache invalidate page(). Currently, theoperating systems view cleancache as a sec-ond level cache (Figure 2). So, when thepage replacement algorithm evicts a cleanpage from page cache, it attempts to put theevicted page into transcendent memory usingcleancache put page(). Later, when file systemwishes to access a page in a file on disk, ituses cleancache get page() to check if the pagealready exists in cleancache, and if it does,the page is copied into the kernel memory,avoiding a disk access. Though this improvesthe file system performance, the extra memoryrequired for redundant storage could be ofconcern in systems with limited RAM likemobile phones. In such systems, the file systemcan use zcache drivers [11, 12] which storespages in the cleancache in a compressed format.

We intend to use cleancache as a protected area,where we can store the application data to pro-tect it from any corrupt kernel pointers or ma-licious driver from overriding. Hence, we pro-pose a slightly modified version of cleancache(Figure 3), in which we consider it as the pri-mary cache for file-backed pages. To read orwrite pages of a file in the cleancache, we ex-tend its interface by adding two APIs - clean-cache grab page() and cleancache write page().cleancache grab page() tries to get a partic-ular page from the cleancache using clean-cache get page() and if the page is not present inthe cleancache, the page is brought into clean-cache from the disk. cleancache write page() isused to write to a page in the cleancache at anyparticular offset within the page: it internallyuses cleancache grab page() to get the page inthe cleancache, modifies the page and puts thepage back in the cleancache. Android file systemcode is routed to these interfaces in case of file-backed pages. cleancache grab page() is calledwhenever an application wants to read a pageof the file, and cleancache write page() is calledwhen application wants to write to a page of the

7

file.

In addition to that, we are deviating from thenormal use case of cleancache, in which it isused by the system to cache clean (i.e. read-only) pages, which may be evicted at any timelater depending upon the working set size of theprocess and the total physical memory of thesystem. In our case, since we are using clean-cache to store dirty pages as well, the pages arewritten to disk when they are evicted from thecleancache. Since all file-backed pages are nowmapped to an area not directly accessible bykernel, corrupt pointer accesses from the kernelwould no longer be able to access the file data.

Another optimization that can be added to themodified cleancache, is the use of zcache driversto store the pages in a compressed form. Thiswould reduce the overall space used by the filecache and could prove very useful in systemswith limited RAM. But there is an extra over-head of compressing and decompressing pageson every read and write to the page.

4 Evaluation

For testing our changes to the file system, weneeded a I/O benchmarking tool. We startedoff by standard benchmarking tools availablefor Android, namely - AnTuTu Benchmark [20],Quadrant Standard Edition [21], SmartBench[22] and CF-Bench [23]. Most of these bench-marking tools calculate a raw score at the endof tests to show the device performance. How-ever, in most cases, the exact interpretation ofthese scores was not known and the scores wereprimarily used as a metric to compare the devicewith other devices. Moreover, since the under-lying implementation of I/O tests was not ex-posed, we found varying results across differentbenchmarking tools, some qualifying our imple-mentation as superior while others did not.

To come up with a better implementation of I/Obenchmarking tool, we decided to implementour own benchmarking tool. While designingthe tool, we came across multiple factors whichcould possibly affect the I/O performance, which

also explains why different benchmarking toolsperformed differently on the same device. Onesuch factor is the storage structures used by thebenchmarking tool.

Android provides several options to save per-sistent application data. The chosen solutiondepends on specific needs, such as whether thedata should be private to the application or ac-cessible to other applications (and the user) andhow much space the data requires[17]. Majordata storage options are the following:

• Shared Preferences: Store private primitivedata in key-value pairs

• Internal Storage: Store private data on thedevice memory

• External Storage: Store public data on theshared external storage

• SQLite Databases: Store structured data ina private database

• Network Connection: Store data on the web

Since external storage is the most common formof storage found in handheld devices, we decidedto use external storage for our benchmarkingtool. The algorithm for measuring performanceis as below:

get_start_time()

repeat for n times

write to file buffer

flush the buffer

issue sync

end repeat

get_end_time()

We ran our benchmarking tests on two sepa-rate environments - Android emulator and Sam-sung Galaxy S3 running Android 4.0.4. Sincewe did not have access to a Android devicewith root privileges, we changed the benchmarktool to skip synchronization requests to emulatethe behaviour we expect in our synchronizationmodel. Note that doing so will underestimatethe time taken to run the benchmark, since thereis a fixed amount of cost associated with call-ing fsync() function. But this cost would be

8

Figure 4: I/O performance on emulated environment

Figure 5: I/O performance on hardware

much lesser than the cost of syncing data todisk. Since our intention is to use real hard-ware as a proof of concept and not for actualcost/benefit analysis, we do not consider this as

a major issue. For more accurate measurements,we planned to run benchmarking tests on Rasp-berry Pi board. But since a stable port for An-droid was not available at the time this work

9

Figure 6: Energy consumption on emulated environment

Figure 7: Energy Consumption on hardware

was done, we are unable to present evaluationresults for Raspberry Pi hardware.

We present I/O performance of our benchmarkon emulated environment and real hardware in

10

Figure 4 and 5 respectively. Clearly, write inten-sive workloads perform better in our implemen-tation. We see a performance speedup of upto143% on emulated environment and upto 155%in real hardware.

An indirect benefit of limiting the disk accessis reduction in costs associated with read andwrite calls[18]. Since getting a page from diskis computationally more expensive operation, itrequires more power to fetch a page from diskwhen compared to getting a page from mem-ory. We test this idea using a power profilingtool called PowerTutor[19]. This tool shows theenergy consumed by an application in Joules.Figures 6 and 7 show the result of power pro-filing using different combination of workloads.As expected, our system outperforms the stan-dard Android kernel and provides significantlycheaper read/write system calls.

An ideal way to evaluate the proposed memoryprotection mechanisms would be through faultinjection. Code to inject various types of faultsinto the kernel could be written, and our protec-tion mechanism could be evaluated on the basisof how many faults the modified kernel is able toprevent. But this process needed an elaboratestudy on the various types of faults and ways toinject faults into the kernel. Due to time lim-itations, we adopt a much simpler method totest our protection mechanism on a per-file ba-sis. During a sys write() system call to writedata to the file under test, since address of thepage is known and the process is running in ker-nel mode we could run our test code to accessthe write-protected page.

5 Conclusions

In our work, we have made a case for persis-tent memory in mobile operating systems. Ourperformance experiments show that using tech-niques defined in the paper, we can achieve con-siderable performance benefits at little or norisk of data loss. For write intensive workloads,our implementation provides significant perfor-mance benefit over conventional Android kernel.

By reducing the disk access frequency, we alsoreduce the cost associated with each read/writerequest, thereby reducing the power consump-tion of all applications.

We also define two approaches to protect in-memory data - write protecting pages and usingtranscendent memory, which provide additionalprotection to data while it resides in main mem-ory. We believe that combination of persistentmemory with protection domains successfullyachieves our goal of designing a file cache whichis fast and reliable at the same time. Moreover,the ideas presented in this paper are generic andcan be applied to any file system implementa-tion.

References

[1] H. Volos, A. J. Tack, and M. M. Swift.Mnemosyne: Lightweight persistentmemory. ASPLOS 11: Proceeding of the16th international Conference onArchitectural support for ProgrammingLanguages and Operating Systems, NewYork, NY, USA, 2011. ACM.

[2] Baker, M., Asami, S., Deprit, E.,Ousterhout, J., and Seltzer, M. (1992).Non-Volatile Memory for Fast, ReliableFile Systems. In Proceedings of the FifthInternational Conference on ArchitecturalSupport for Programming Languages andOperating Systems (ASPLOS-V), pages1022.

[3] Jorge Guerra, Leonardo Marmol, DanielGalano, Raju Rangaswami, and JinpengWei. Software persistent memory. FIUSCIS Technical Report TR-2010-12-01,2010.

[4] Jason Gait. Phoenix: A Safe In-MemoryFile System. Communications of theACM, 33(1):81-86, January 19, 1990.

[5] A.-I.A. Wang et al., Conquest: BetterPerformance through aDisk/Persistent-RAM Hybrid File System,Proc. 2002 USENIX Ann. Technical Conf.,June 2002.

11

[6] P. M. Chen, W. T. Ng, S. Chandra, et al.The Rio File Cache: Surviving OperatingSystem Crashes. In Proc. of the 7th Int’l.Conf. on ASPLOS, pages 74-83, 1996.

[7] Ng, N. T. and Chen, P. M. 2001. Thedesign and verication of the Rio le cache.IEEE Trans. Comput. 50, 4, 322337.

[8] M. Baker and M. Sullivan. The recoverybox: Using fast recovery to provide highavailability in the UNIX environment.Proc. of the Summer USENIX Conf., June1992.

[9] D. Magenheimer, C. Mason, D.Mccracken, K. Hackel, and O.Corporation, Transcendent memory :Re-inventing physical memorymanagement in a virtualized environment,OSDI 08 WIP session, 2008, pp. 167-193.

[10] D. Magenheimer and O. Corp,Transcendent Memory on Xen, XenSummit, 2009, pp. 1-3.

[11] Nitin Gupta. compcache: Compressedcaching for linux.http://code.google.com/p/compcache/,Accessed Oct. 2012.

[12] Nitin Gupta, zcache: page cachecompression support.http://lwn.net/Articles/396467/, AccessedOct. 2012.

[13] Crispin Cowan, Calton Pu, Dave Maier,Heather Hinton, Jonathan Walpole, PeatBakke, Steve Beattie, Aaron Grier, PerryWagle, and Qian Zhang. Stackguard:Automatic adaptive detection andprevention of buffer-overflow attacks. In7th USENIX Security Symposium, SanAntonio, Texas, January 1998.

[14] Crispin Cowan, Perry Wagle, Calton Pu,Steve Beattie and Jonathan Walpole.Buffer Overflows: Attacks and Defensesfor the Vulnerability of the Decade.DARPA Information SurvivabilityConference and Exposition. January 2000.

[15] David Wagner, Jeffrey S. Foster, Eric A.Brewer and Alexander Aiken. A First StepTowards Automated Detection of BufferOverrun Vulnerabilities. Network andDistributed System Security Symposium.

February 2000.[16] Android Open Source, Google, 2010. Web.

http://source.android.com/source/index.html[17] H. Kim, N. Agrawal, and C. Ungureanu,

Examining storage performance on mobiledevices, in Proceedings of the 3rd ACMSOSP Workshop on Networking, Systems,and Applications on Mobile Handhelds(MobiHeld), 2011.

[18] A. Carroll and G. Heiser. An analysis ofpower consumption in a smartphone. InUSENIX, 2010.

[19] Z. Qian Z. Wang R. P. Dick Z. Mao L.Zhang, B. Tiwana and L. Yang. Accurateonline power estimation and automaticbattery behavior based power modelgeneration for smartphones. In Proc. Int.Conf. Hardware/Software Codesign andSystem Synthesis, 2010.

[20] AnTuTu Labs. AnTuTu Benchmark.http://www.antutulabs.com/antutu-benchmark, Accessed Oct.2012.

[21] Aurora Softworks. Quadrant StandardEdition. http://www.aurorasoftworks.com,Accessed Oct. 2012.

[22] SmartBench.http://smartphonebenchmarks.com,Accessed Oct. 2012.

[23] CF-bench. CPU and memory benchmarktool.http://www.chainfire.eu/projects/46/CF-Bench/, Accessed Oct.2012.

12