Messages in this thread | | | From | "Adam J. Richter" <> | Date | Fri, 29 May 1998 08:40:52 -0700 | Subject | Re: bzip2 compression of kernel or initial ramdisk? |
| |
From a Frequently Questioned Answers List (a cute term I picked up from some cipherpunks discussion) apparently by "Scott" and reposted by "Paul" <PELaufer@CSUPomona.edu>:
> 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
| |