> bzip is *much* more CPU-expensive and needs external buffers to
>decompress.
> gzip can decompress in place, which it why we use it to compress the
> kernel image. The sources are bzipped on kernel.org as a
> convenience. gzip is faster, gzip is preferred. If the bzipped
> images cause too much griping, they will be removed.
I have investigated this further, and here is what I have
discovered.
On a 300MHz Pentium II, decompressing a 2 megabyte (823kB
bzip'ed) romfs ramdisk took 1.72 CPU seconds more than with gunzip,
presumably about 70 seconds on a 25MHz 386, a factor of almost 9
versus gunzip. An a fast enough machine, much of this time difference
would be recovered by not having to read as much from the floppy drive.
After estimating the additional space needed for bunzip2 code
in the kernel, it appears that bunzip2 would save about 28kB (70kB
uncompressed). If the kernel and the ramdisk decompressors could be
combined at a space cost of the size of the current kernel
decompressor, that would free another 22kB (52kB uncompressed) for a
total space savings of about 50kB compressed / 122kB uncompressed.
THE GORY DETAILS:
% time gunzip < initrd.gz > /dev/null
real 0m0.278s
user 0m0.210s
sys 0m0.060s
% time bunzip2 < initrd.bz2 > /dev/null
real 0m2.465s
user 0m1.930s
sys 0m0.090s
An additional elapsed wall clock time difference was probably due
to read strategy, which would not be an issue with bzip2 decompression
of an initial ramdisk, since the decompressor runs with the compressed
ramdisk completely loaded into memory.
% ls -l initrd initrd.gz initrd.bz2
-rw-r--r-- 1 root system 2020352 May 29 06:40 initrd
-rw-r--r-- 1 root system 822904 May 29 06:42 initrd.bz2
-rw-r--r-- 1 root system 857554 May 29 06:42 initrd.gz
% ls -l /usr/src/linux/vmlinux
-rwxr-xr-x 1 root system 1147375 May 29 03:13 /usr/src/linux/vmlinux*
% gzip -9 < /usr/src/linux/vmlinux | wc -c
513685
% bzip2 -9 < /usr/src/linux/vmlinux | wc -c
491178
Reducing bzip2 to a program that only did decompression from
standard input to standard output with no arguments resulted in a
stripped ELF .o file 19,312 bytes long. The kernel object file for
the ramdisk driver with gunzip decompression compiled in is 12,064
bytes, stripped. So, switching from gunzip to bzip2 would add 7-20kB
to the kernel, which would compress to 2.5-8kB, based on the 2.5
compression ratio that the rest of the kernel seems to get with gzip.
bzip2 -9 saves 34,650 versus gzip -9 when compressesing the 2MB
ramdisk previously mentioned. If we assume 6kB would be lost due to
the size of compressed bunzip2 code, the expected savings is 28,650
bytes compressed, or 70,340 bytes prior to bzip2 -9 compression.
I am not sure what is meant by "gzip can be used in place."
Both decompressors need malloc and the bounds of the memory usage of
both decompressors is believed to be well understood, although bzip2
uses more memory. I believe the ramdisk decompressor has access to
kmalloc and kfree at the time that it runs, although the kernel
decompressor does not.
It appears that a bzip2'ed initial ramdisk and kernel would
probably be worth doing for many circumstances, but, as measured by
boot floppy kilobytes saved per programmer hour invested, it will
probably be more effective to exhaust the following avenues first:
1. recheck for kernel options that are not useful in a fully
modularized configuration
2. modularize the few remaining drivers that do not need to
be on an initial boot floppy,
3. attempt to reduce module duplication between the main
kernel distribution and the PCMCIA drivers,
4. more carefully strip kernels from module .o files and
the pruned shared glibc built into the ramdisk,
5. investigate getting better compression by extending the
window sizes in gzip beyond what gzip -9 provides. This
will probably require using a different format change
changes some 16 bit numbers to 24 or 32 bit numbers.
6. combine some duplicative code within the kernel image, probably
starting with multiple copies of the decompression code.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 205
adam@yggdrasil.com \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu