Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!agate!darkstar!june.cs.washington.edu From: pardo@june.cs.washington.edu (David Keppel) Newsgroups: comp.os.research Subject: Re: compress/decompress paging? prepaging? Message-ID: <280@darkstar.ucsc.edu> Date: 14 Jun 89 17:00:14 GMT Sender: usenet@darkstar.ucsc.edu Organization: U of Washington, Computer Science, Seattle Lines: 42 Approved: comp-os-research@jupiter.ucsc.edu wilson@carcoar.stanford.edu (Paul Wilson) writes: >[I'm looking for information on paging with compression.] >[Goal: use compression for RAM caching of pages] Our moderator writes: >[It has to be FAST] >[Pages going to 2ndary store aren't fixed-size] Here's my guess: * Pages are compressed in-core. Unless you know a lot about the data you're compressing, a fast algorithm probably won't buy much more than 50%. Probably separate compression algorithms are in order for the code space and the data space(s). * The pages are stored in-core in adjacent memory. (This is what you would assume: If page 1 is 100 bytes compressed and stored at location 2000, then page 2 is stored starting at location 2100). * You'll want to store the compressed data pages on full-page allocations. When you want page _x_, you don't want to have to figure out which sectors it lives on, you just want to go get it. Indeed, if bandwidth is high, you might want to store them on the disk in *uncompressed* form. If you need it, you're going to need it uncompressed (unless you are doing clever prefetching). * You may have some problems on some architectures. The VAX, for instance, stores 4 bytes for each page. The bytes include some protection info, so there are less than 32 address bits per page. Those 32 bits are used normally for either (a) the physical page frame number (22 bits) or for a disk block number (?? bits, < 32). If the pages are compressed, then they will live at odd addresses and will most generally require 30+ bits for each compressed page address. Hope this is useful. ;-D on ( A page from the history books ) Pardo -- pardo@cs.washington.edu {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo