Greetings-
I patched the kernel decompression and the ramdisk decompression
to use bzip2 instead of gzip (for tomsrtbt), is there sufficient
interest or openness to this that I should clean it up and fixup
the config stuff or is this something of such limited usefulness
that I should just keep it here?
In the past I have seen discussion to the effect that the memory
and CPU usage of bzip2 is so much higher that there is no point,
of course, that discussion was about _requests for a patch_, and
it seems possible that it might be seen as of greater use in the
context of _fait accompli_ (?sp).
The tradeoffs are obvious- it takes less space on the media (for
both the kernel and the root ramdisk), but massively more memory
and CPU time. Perhaps only something like tomsrtbt is willing to
pay the price...
Any-way, the patch as it stands, (that is, it works, but has not
been prettied up for prime-time) is available if anyone cares at:
http://not.toms.net/tomsrtbt-sources/bz2.diff
-Tom Oehser, [email protected]
On Mon, 29 Apr 2002, Jeff Garzik wrote:
> I made this patch for 2.2.x kernels long ago, and if you search
Ah. But it looks like you only patched the ramdisk loader, I did
the bootloader also. My intention is that it would be used as a
replacement for the gzip thoughout, the kernel I have on tomsrtbt
2.0.88 does the bzip2 kernel load and bzip2 ramdisk load, and does
not include the gzip code at all.
As for figures-
I have only tested with bzip2 -9, and my patch only supports small
(not fast), (remember that I'm coming from a floppy diskette...).
I'm aiming for compression then memory then speed, so, I don't have
numbers for what bzip2 -1 or fast-RLE would be like. Moreover, the
tomsrtbt is loading a 4MB ramdisk from a 1.722 floppy, so I'm not
testing memory usage beyond pass/fail on an 8MB machine.
In _my_ configuration, (tomsrtbt 2.0.88), the numbers (to the best
accuracy I have, using the current best measure I have performed):
Size:
gzip bzip2 savings
Kernel 862209 831381 30828
Ramdisk 939474 880756 58718
______ ______ _____
Total 1801683 1712137 89546
Speed Memory
Gzip Lightning Thimble
Bzip2 Molasses Bathtub
-Tom
(First, I apologize for getting a 'vger.rutgers.org' into a mail header
instead of 'vger.kernel.org', probably causing every reply to bounce...)
On Mon, 29 Apr 2002, Linus Torvalds wrote:
> On Mon, 29 Apr 2002, Tom Oehser wrote:
> >
> > Speed Memory
> >
> > Gzip Lightning Thimble
> >
> > Bzip2 Molasses Bathtub
>
> While I appreciate the extensive scientific testing and regression that
> went into these numbers, I think that the main thing that matters is
> whether the bathtub of memory makes it harder to boot on a 4-8MB system,
> and whether the molassic speed makes the boot noticeably slower on older
> 486-class machines despite a faster load phase..
>
> Do you have any statistics for this? Can you answer that age-old question
> of how many bathtubs can dance on the head of a 4MB machine?
>
> Linus
It fits and works on a 4MB machine with no problems, my 831K-compressed bzip2
-9 kernel works on a 4MB box, ... *if* I'm not also loading a 4MB ramdisk ...
Specifically, the window allocated in misc.c is 32K, bzip2 using 'small'
varies between 350K for a -1 compressed file and 2350K for a -9 compressed
file. (My previously posted compression numbers are for -9.)
The decompress time for bzip2 -d -s is about 14 times slower than gzip.
If you are booting a 386 from striped U2W arrays, it would for sure be
'noticably slower'. If, however, as is more common with tomsrtbt, you are
booting for the purpose of rescue and recovery, from a grinding floppy drive,
it is probably never slower enough to matter, even on a 486. I certainly
only consider it appropriate for situations where this trade off makes sense.
Floppies and flash memory come to mind, but not hard drives.
-Tom