lkml.org 
[lkml]   [2003]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Swap Compression
On Mon, 28 April 2003 02:52:15 -0600, Eric W. Biederman wrote:
> JXrn Engel <joern@wohnheim.fh-wedel.de> writes:
>
> > Yes, zlib eats up several 100k of memory. You really notice this when
> > you add it to a bootloader that was (once) supposed to be small. :)
>
> I only measured about 32k for decompression. But that was using
> the variant from gzip via the kernel.

What were you measuring? Code size or runtime memory consumption? It
looks a bit large for code size, but _very_ small for runtime.

> The really small algorithm I know about (at least for decompression)
> is upx. The compression is comparable with gzip with a decompressor
> that can fit in a page or two of assembly code.

Sounds interesting as well. Maybe we should add a central compression
library to the kernel. zlib is already central, but at least jffs2 and
ppp also have some other algorithms that could be moved and possibly
reused for other subsystems/drivers.

Jörn

--
Optimizations always bust things, because all optimizations are, in
the long haul, a form of cheating, and cheaters eventually get caught.
-- Larry Wall
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:35    [W:0.118 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site