Re: Swap Compression

[Con Kolivas <kernel@kolivas.org>]

On Tue, 29 Apr 2003 07:35, Timothy Miller wrote:
> 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.

The work that Rodrigo De Castro did on compressed caching 
(linuxcompressed.sf.net) included a minilzo algorithm which I used by default 
in the -ck patch addon as it performed the best for all the reasons you 
mention. Why not look at that lzo code for adoption.

Con