Re: Swap Compression

[Timothy Miller <miller@techsource.com>]

rmoser wrote:

>Yeah you did but I'm going into a bit more detail, and with a very tight algorithm.  Heck the algo was originally designed based on another compression algorithm, but for a 6502 packer.  I aimed at speed, simplicity, and minimal RAM usage (hint:  it used 4k for the code AND the compressed data on a 6502, 336 bytes for code, and if I turn it into just a straight packer I can go under 200 bytes on the 6502).
>
>Honestly, I just never looked.  I look in my kernel.  But still, the stuff I defined about swapon options, swap-on-ram, and how the compression works (yes, compressed without headers) is all the detail you need about it to go do it AFAIK.  Preplanning should be done there--done meaning workable, not "the absolute best."
>  
>
I think we might be able to deal with a somewhat more heavy-weight 
compression.  Considering how much faster the compression is than the 
disk access, the better the compression, the better the performance.  

Usually, if you have too much swapping, the CPU usage will drop, because 
things aren't getting done.  That means we have plenty of head room to 
spend time compressing rather than waiting.  The speed over-all would go 
up.  Theoretically, we could run into a situation where the compression 
time dominates.  In that case, it would be beneficial to have a tuning 
options which uses a less CPU-intensive compression algorithm.

>  
>