[lkml]   [1998]   [Feb]   [21]   [last100]   RSS Feed
Messages in this thread
SubjectRe: New Feature Idea: Compress swap file
>  - Our objective is performance, by reducing the amount of read/write to the

Also reduces the size of swap in use which provides more usable VM for a
given amount of disk space, however this makes swap requirements less
predictable (the system could run out of memory by changing some data to less
regular patterns). If we reduce the amount of swap space required then we
should reduce the amount of seeking done to access swap, as well as decreasing
the data transfers.
If we can compress a page to less than the sector size is it worth while?
If we have a page compressed to 256 bytes then we can fit another 256 byte
page in the same disk sector, if we have to read the sector in before writing
are we gaining anything? Perhaps we could just store such easily compresible
pages in memory first where we could retrieve them rapidly by decompression.
Then if we decide to finally send the data to disk we can do it 2 pages at a
time so we can do a single sector write to store 2 pages (this seems good).
However if one of those pages gets accessed again then we end up with a sector
containing a page which is compressed to <256 bytes and which has 256+ bytes
free, but I guess even if such fragmentation becomes rampant we still win by
having such a page take 512 bytes instead of 4K or 8K (depending on the
Also some time ago Ingo Molnar wrote a patch to count swap-outs of pages
which were filled with zeros. It was found that the systems tested had around
1% of pages filled with zeros. There was discussion about writing a patch to
check for zero pages and make them the copy-on-write zero page, but it was
decided that it wan't worth while. If we install swap compression then
checking for zero pages would be a trivial part of the work and probably would
be worth-while. It'd also make some fortran programmers happy...

> - We can minimize the time wasted on compression by not compress code
>pages, only
> data pages. What's the (normal expected) relation of code/data pages?

Currently we don't swap out code pages, we discard them. There has been
talk of adding a feature whereby code pages from slow devices (NFS and CD-ROM)
could be paged out to a fast local disk. AFAIK nothing concrete has been done
about it though.

Russell Coker

the body of a message to

 \ /
©2003-2011 Jasper Spaans