Design of Compressed RAM in Android · Swapping is the process of swapping out the anonymous pages...

Design of Compressed RAM in Android

M.Tech Project Stage-II

Subbanjaneyulu Reddy P.N (113050021)

Under the Guidance ofProf. D.B.Phatak

Department of Computer Science and Engineering,Indian Institute Of Technology , Bombay

June 23, 2013

(Subbanjaneyulu Reddy P.N) Design of Compressed RAM in Android June 23, 2013 1 / 46

INTRODUCTION

OVERVIEW

This presentation gives an overview of the following:

Linux page Frame Reclaiming Algorithm

Memory management in Android

Compressed RAM

Comparison of compression algorithms

Enhanced Compressed RAM


Motivation

Flash memory suffers from ware leveling issues[18]. Android devices usesFlash memory as secondary storage. Swapping involves writing of contentto swap device.As a result :

Android does not have swap space

Killing of applications at low memory situations


Problem Statement

Objective :

Use part of a RAM as swap space and compress the content writtento this space (Compressed RAM)

This increases effective memory

Reduces in killing of applications

Design of Compressed RAM



Linux page Frame Reclaiming Algorithm ( LFRA ) - ensures there issome free memory at every point of time[6]

It reclaims frames

Linux maintains two LRU lists

Invoked at Low memory situations, Hibernation, Periodically


Linux Page Frame Reclaiming Algorithm

Classification of pages

Type Description Action

Unreclaimable Locked pages, Kernelmode stacks, free pages,reserved paged

Impossible

Swappable Anonymous user modepages

Write toswap area

Syncable Mapped pages which arepart of file

Write to file

Discarded Unused pages Nothing tobe done

Table: Classification of pages[6]



Discarded pages are given high priority

Syncable clean pages are reclaimed by making frame free

Syncable dirty pages are written to disk

Swappable pages are written to swap space


Swapping

Swapping is the process of swapping out the anonymous pages to disk

Anonymous pages, pages belonging to an IPC shared memory

Process having largest number of pages in RAM[5]

Pages of selected process are reclaimed in LRU approach


Android memory management

Android does not have swap space [12]

Android has Low Memory Killer along with Out of Memory Killer

Low Memory killer kills applications at low memory situations

Out of Memory Killer kills when memory is exhausted


Compressed RAM

Android does not have swap space because of the following reasons[15] :

Memory is scarce and adding more memory increases device costs

Flash storage suffers from wear-leveling issues

Compressed RAM uses part of RAM to compress the pages and store them.


Compressed RAM

CRAMES depends on Linux swapping mechanism[11]

CompCache also depends on Linux swapping mechanism [15]

Compression Cache depends on LRU list [8]


Compressed RAM approach

Set part of the RAM as compressed area

Pages are written to compressed area usually at low memory situations

The pages written to this area are compressed and stored

The selection of pages to be compressed is depended on Linuxswapping mechanism

Linux swapping mechanism is based on LRU approach[11]

When page in Compressed area is accessed, it is uncompressed andstored in uncompressed part of RAM


Request handling

Write Request :

Compressing a block that is to be written

Allocating memory for a compressed block and placing thecompressed block in allocated memory

Managing the mapping table

Attempting to merge free slots


Request handling

Read Request :

Locating a compressed block with an index number

Decompressing a block that is read from the device

Releasing the memory occupied by this compressed block

Managing the mapping table

Attempting to merge free slots


Compression Algorithms

Compression should be lossless

Take less memory[1]

Asymmetric

Good compression ratio

Faster in computation



We have compressed 1023065 main memory pages using four well knowcompression algorithms.Experimental setup :

Operating System :- Ubuntu 12.04

RAM :- 4GB

Processor :- Intel i3 @ 3.30 GHZ

Total Number of pages considered :-1023065



Compression Ratio Compression ratio is ratio of size of data beforecompression and size of data after compression[1].

Figure: Average Compression Ratio



Decompression Time The below figure shows the average decompressiontime to decompression a page

Figure: Average Decompression time



Compression Time The below figure shows the average decompressiontime to decompression single page, two pages, three pages

Figure: Average Compression time



Good compressible pages The below figure shows the count of pageswith compression ratio >= 2

Figure: Number of pages whose size is reduced by half after compression



Incompressible pages The below figure shows the count of pages withcompression ratio < 1

Figure: Number of pages whose size increases after compression



Statistics of Zlib The below figure shows the percentage of pages with1/compression-ratio in the range

Figure: Percentage of pages with 1/compression-ratio in the range



Observations

Decompression time and Compression time are asymmetric

The time to compress in not propositional to size

There are almost 3-5 percentage of pages whose size increases aftercompression



Observations

There are almost 10 percentage of page whose size is 75 percentageafter compression even in best performed ZLIB algorithm

Selecting a page from such a list will not help us to save memory

The LZO and ZLIB performs well.

Its a tradeoff to select among LZO and ZLIB

ZLIB performs better than LZO at the cost of more compression &decompression time.



Pages to be selected

Unreclaimable pages

Discarded pages

Syncable pages

Swappable pages



Properties of pages

Access Time

Compression Ratio



We maintain two lists, LRU list and sec list

LRU list contains pages whose compression ratio is not known

sec list contains pages whose compression ratio is known

Each page in RAM will have entry in either LRU list or sec list



Compression ratio of the page depends on the page content

When a page is selected for compression we will update itscompression ratio parameter

If size of the page after compression does not reduce much it is notstored in the compressed area



Algorithm 1 Enhanced Compressed RAM Page Selection

1: List lru;2: List sec;3: Set part of the RAM as compressed area4: Maintain two lists lru list and sec list5: Initially as compression ratio of any page is not known, every page in

RAM have entry in lru list6: At low memory situations call lowMemoryHandler()7: when a page is accessed call pageAccessHandler()


Enhanced Compressed RAM page


1: function pageAccessHandler

2: if read access then3: if Page in Uncompressed Area then

4: Update its position in the list;5: else if Page in Compressed Area then

6: Uncompress it, place it in compressed area and add it to sec;7: else

8: handle pagefault;9: end if

10: end if

11: end function




1: function pageAccessHandler

2: if write access then3: if Page in Uncompressed Area then

4: Update its position in the list;5: else if Page in Compressed Area then

6: Uncompress it, place it in compressed area and add it to lruas the compression ratio is no more valid;

7: else

8: handle pagefault;9: end if

10: end if

11: end function



Algorithm 4 Enhanced Compressed RAM Page Selection1: function lowMemoryHandler( )

2: pid= process with highest number of pages in RAM

3: while low memory situation do

4: score1 = lru.tailelementofprocess(pid).accesstime/10 + 10;

5: ele = sec.tailelementofprocess(pid);

6: score2 = ele.accesstime/10 + 100/(ele.compressionratio ∗ 5)

7: if score1 < score2 then

8: select page from lru and compress it;

9: if size after compression > 75 % of page size then

10: remove it from lru, set its compression ratio;

11: add it to sec;12: else

13: remove it from lru, allocate memory in compressed area;

14: free the Frame;15: end if

16: else

17: select page from sec, remove it from sec, allocate memory in compressed area;

18: free the Frame;19: end if

20: end while

21: end function


Simulation(1)

We have simulated both the approaches.Simulation setup :-

Number of frames in RAM are 1000

Compressed area size 100 pages

Low memory threshold : 100 pages

High memory threshold : 200 pages

Compression algorithm used Zlib

Scheduling algorithm followed Roundrobin


Simulation(2)

Simulation setup :-

Time quantum for each process 1 milli seconds

Page access events are randomly generated

Read/Write page miss processing time 100 micro seconds

Read/Write page hit processing time 1000 nano seconds

Time taken to compress/decompress 100 nano seconds


Simulation-Results

Memory Utilization The below figure shows the memory utilization inboth the approaches

Figure: Free memory with respective to time (in milli secs)


Simulation-Results

Memory saving The below figure shows the number of pages stored incompressed area in both the approaches

Figure: Number of pages in compressed area


Simulation-Results

Overhead The below figure shows the number of compressions anddecompressions in both the approaches

Figure: Number of compressions & decompressions


Conclusions

Modern devices with no swap space results in killing of process at lowmemory situations

Use of Compressed RAM as swap will increase effective memory andavoids killing of applications to some extent

Zlib and LZO performs well.

Is tradeoff to choose among Zlib and LZO


Conclusions

There are more than 10 % of pages whose size is more than 75 % ofpage size after compression even in best performed Zlib

Depending on Linux kernel swapping for Compressed RAM will notgive good performance

Enhanced Compressed RAM is able to store double the pages incompressed area than in Compressed RAM


Further work

Implementing the proposed system on Android device

We have invalidated the compression ratio when a page is writeaccessed. Using the same compression ratio even after write access

Finding the compression ratio of dirty pages i.e whose compressionratio is not valid when CPU is idle


REFERENCES I

Nitin Gupta Anderson Farias Briglia, Allan Bezerra.Evaluating effects of cache memory compression on embeddedsystems.2007 Linux Symposium, 2007.

Peter M Chen.Memory management in os.

Toni Cortes, Yolanda Becerra, and Ral Cervera.Swap compression: resurrecting old ideas.Software: Practice and Experience, 30(5):567–587, 2000.

Activity Life cycle.http://developer.android.com/reference/android/app/activity.html,last accessed March 2013.


REFERENCES II

Marco Cesati Daniel P. Bovet.Understanding the Linux Kernel, 1st Edition.O’Reilly, October 2000.

Marco Cesati Daniel P. Bovet.Understanding the Linux Kernel, 3rd Edition.O’Reilly, november 2005.

Dhananjay M Dhamdhere.Operating System Concept base approach.McGraw-Hill Higher Education, 2009.

Fred Douglis.The compression cache: Using on-line compression to extend physicalmemory.In In Proceedings of 1993 Winter USENIX Conference, pages519–529, 1993.


REFERENCES III

Jean-loup Gailly, Mark Adler.http://zlib.net, last accessed April 2013.

Julian.http://www.bzip.org, last accessed April 2013.

ROBERT P. DICK LEI YANG.Online memory compression for embedded systems.ACM Transactions on Embedded Computing Systems, 2010.

Android Memory Management.http://mobworld.wordpress.com/2010/07/05/memory-management-in-android, last accessed October2012.

Markus F.X.J. Oberhumer.http://www.oberhumer.com/opensource/lzo, last accessed April 2013.


REFERENCES IV

Miguel Masmano, Ismael Ripoll, Patricia Balbastre, and AlfonsCrespo.A constant-time dynamic storage allocator for real-time systems.Real-Time Systems, 40(2):149–179, 2008.

Compressed Cache on Linux by Nitin Gupta.http://code.google.com/p/compcache/, 2008.

Hung-Wei Tseng, Han-Lin Li, and Chia-Lin Yang.An energy-efficient virtual memory system with flash memory as thesecondary storage.In Low Power Electronics and Design, 2006. ISLPED’06. Proceedings

of the 2006 International Symposium on, pages 418 –423, oct. 2006.

M.I. Vuskovic.Virtual memory in operating system lecture notes, last accessedOctober 2012.


REFERENCES V

Wikipedia.http://en.wikipedia.org/wiki/Flashmemory, last accessed Jan 2013.

Ramani Yellapragada.Linux Memory Management.2003.


Thank You


Design of Compressed RAM in Android · Swapping is the process of swapping out the anonymous pages...

Documents

Transcript of Design of Compressed RAM in Android · Swapping is the process of swapping out the anonymous pages...