Re: Where's the bzip2 compressed linux-kernel patch?

From: Willy Tarreau
Date: Sun Oct 19 2003 - 23:31:52 EST


On Sun, Oct 19, 2003 at 07:00:47PM -0500, Rob Landley wrote:
> upx is upx-1.22.
>
> So you're talking about something that compresses LESS well than gzip. Why?

I'm not talking about something that compresses LESS than gzip, I'm talking
about something I almost always use to recompress my kernels and reduce their
size by 20% over gzip, and decompress way faster.

It's upx-1.90 (which is able to decompress/recompress bzimage). OK it's still
a development version, but it has already saved me megs of flash.

I don't know how the tests above were done. But what I know for sure is that
there are excessive open source zealots who would only download the OSS
version of UPX which uses the UCL library while the closed source version
uses the NRV one which is a jewel.

And you know what ? when I put a complete distro on a 8MB flash, my primary
concern is to save as much space as possible, and my ability to read the
compressor sources only comes next.

BTW, I don't remember every upx argument, but I'm sure I got best numbers
with '--best --crp-ms=100000'.

> And no, gzip -9 does not add anything to decompression time, only
> compression time.

Where did you get this interesting idea ? every decompressor needs
decompression time. You need the compressed kernel to be in memory, then you
decompress it, then you boot it. On my old 386sx which was still my home
firewall 6 months ago, the kernel would take 2-3 seconds to decompress with
gzip while it was almost unnoticeable with upx (which did it in place, BTW).

Now don't get me wrong, I'm not advertising for upx. But bzip2 was proposed
and will always be criticized because of its decompression time and cost in
terms of memory. So I simply suggested to take a look at other solutions
which seem interesting. An UPX-based implementation seems interesting to me
only if the decompression code is free and can be put in the kernel. Otherwise
it is not. If the numbers above come from the UCL lib, then we at least know
that this one doesn't interest us for this matter. Some people would also
suggest taking a look at other compression algorithms which can be of
interest, but I don't know their sources status (open/close).

> I can make bunzip work in-place if you'd like

That's very important for low-memory systems.

Regards,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/