>The problem with swapping isn't throughput (which compression could help
>IF you had enough CPU horsepower, which you don't), but access time, which
>compression will always hurt. So, compressing pages before swapping them
>to disk will decrease performance.
>
>However, an i486-66 with gzip can compress at the same speed as it can read/
>write random pages on a moderately quick disk (12ms); and can decompress
>significantly faster.
>
>So, with some memory access patterns, on most hardware (486-DX2 or
>faster with a contemporary drive; or a slower system + older drive),
>assuming you can achieve the right balance between "swap" memory usage
>and page cache, you could achieve a performance increase by compressing
>pages in-core.
Actually, after thinking about it a little more, I guess you're right.
The amount of time the drive needs to do the seek is going to be the
same, so the issue is one of whether the time taken to
compress/transfer or transfer/decompress a page is less than the time
it takes to just do the straight transfer....
Now, hmmm.... if the page is old, and kswapd is swapping it out, the
time it takes to swap out would not be much of an issue. And some gain
might be seen if it was indeed faster to read in and decompress the
page when it was needed...
I guess the question then boils down to what kind of compression ratio
you can get on the default page size?
Christopher Horn
chorn@warwick.net