Hi.
On Tue, 2006-08-29 at 06:05 +0200, Jan Engelhardt wrote:I am throwing in gzip: would it be meaningful to use that instead? The decoder (inflate.c) is already there.For Suspend2, we ended up converting the LZF support to a cryptoapithanks for the info, we will compare themHmm. LZO is the best compression algorithm for the task as measured byI don't think that LZO beats LZF in both speed and compression ratio.
the objectives of good compression effectiveness while still having very
low CPU usage (the best of those written and GPL'd, there is a slightly
better one which is proprietary and uses more CPU, LZRW if I remember
right. The gzip code base uses too much CPU, though I think Edward made
LZF is also available under GPL (dual-licensed BSD) and was choosen in favor
of LZO for the next generation suspend-to-disk code of the Linux kernel.
see: http://www.goof.com/pcg/marc/liblzf.html
plugin. Is there any chance that you could use cryptoapi modules? We
could then have a hope of sharing the support.
06:04 shanghai:~/liblzf-1.6 > l configure*
-rwxr-xr-x 1 jengelh users 154894 Mar 3 2005 configure
-rwxr-xr-x 1 jengelh users 26810 Mar 3 2005 configure.bz2
-rw-r--r-- 1 jengelh users 30611 Aug 28 20:32 configure.gz-z9
-rw-r--r-- 1 jengelh users 30693 Aug 28 20:32 configure.gz-z6
-rw-r--r-- 1 jengelh users 53077 Aug 28 20:32 configure.lzf
We used gzip when we first implemented compression support, and found it
to be far too slow. Even with the fastest compression options, we were
only getting a few megabytes per second. Perhaps I did something wrong
in configuring it, but there's not that many things to get wrong!