Virtual memory compression: Difference between revisions

Revision as of 03:49, 9 January 2015

Revision as of 16:44, 10 January 2015

Line 18:

===Low compression ratios===

One of the primary issues is the degree to which the contents of primary storage can be compressed under real-world loads. Program code and much of the data held in primary storage is often not highly compressible, since efficient programming techniques and data architectures are designed to automatically eliminate redundancy in data sets. Various studies show typical [[data compression ratio]]s ranging from 2 to 2.5 for program data.<ref name="SIMPSON"/><ref name="RIZZO"/>

===Background I/O===

Line 26:

Less obvious is the fact that the memory used by the compression system reduces the available system memory and thus causes a corresponding increase in overall paging activity. As more primary storage is used to store compressed data, less primary storage is available to programs, causing the level of paging activity to increase, reducing the effectiveness of the compression system.

Since theThe relationship between paging activity and available memory is roughly exponential.<ref name="DENNING"/><ref name="FREEDMAN"/> This means that for a given reduction, x, in available memory there will be an exponential increase in paging activity on the order of <math>e^x</math>. In circumstances where memory is low and paging is fairly prevalent, any gains in available memory tend tomay be offset by significant increases in paging/[[thrashing (computer science)|thrashing]].<ref name="DENNING"/> Again, the more compressible the data, the more pronounced the performance improvement, because less primary storage is needed to hold the compressed data.

For example, in order to maximize the use of the primary storage cache of compressed pages, [[Helix Software Company]]’s Hurricane 2.0 provides a user-configurable threshold that allows the rejection level for compression to be adjusted. The program would compress the first 256 to 512 bytes of a 4&nbsp;KiB page and if that small region achieved the designated level of compression, the rest of the page would be compressed and then retained in a primary storage buffer, while all others would be sent to auxiliary storage through the normal paging system. The default setting for this threshold was an 8:1 compression ratio.<ref name="PCMAG-HURR-2"/>

Line 72:

number = 5875474 |

status = patent}}</ref>

<ref name="SIMPSON">

{{cite web|

last = Simpson |

first = Matthew |

title = Analysis of Compression Algorithms for Program Data|

year = 2014 |

url = http://www.ece.umd.edu/~barua/matt-compress-tr.pdf |

accessdate = 2015-01-09 |

pages = 6 }}</ref>

<ref name="RIZZO">

{{cite journal|

last = Rizzo |

first = Luigi |

title = A very fast algorithm for RAM compression |

journal= ACM SIGOPS Operating Systems Review |

year = 1996 |

url = http://dl.acm.org/citation.cfm?id=250012 |

accessdate = 2015-01-09 |

page = 8 }}</ref>

<ref name="DENNING">

{{cite journal|
last = Denning |

first = Peter J. |

title = Thrashing: Its causes and prevention |

Line 81 ⟶ 103:

url = http://www.cs.uwaterloo.ca/~brecht/courses/702/Possible-Readings/vm-and-gc/thrashing-denning-afips-1968.pdf |

accessdate = 2015-01-05 |

pagespage = 918 |

volume = 33}}</ref>

<ref name="FREEDMAN">

{{ cite web|

last = Freedman |

First = Michael J. |

*title [http://www.cs.princeton.edu/~mfreed//docs/6.033/compression.pdf= The Compression Cache: Virtual Memory Compression for Handheld Computers], March 16, 2000, by Michael J. Freedman|

url = http://www.cs.princeton.edu/~mfreed//docs/6.033/compression.pdf |

date = 16 March 2000 |

accessdate = 2015-01-09}}</ref>

<ref name="PCMAG-HURR-2">

Line 174 ⟶ 205:

== External links ==

* [http://www.cs.princeton.edu/~mfreed//docs/6.033/compression.pdf The Compression Cache: Virtual Memory Compression for Handheld Computers], March 16, 2000, by Michael J. Freedman

{{-}}