Messages in this thread |  | | | Date | Wed, 18 Jul 2007 15:17:36 -0700 | | From | "H. Peter Anvin" <> | | Subject | Re: Patches for REALLY TINY 386 kernels |
| |
Andi Kleen wrote: >> >> However, compressed size reductions as an abstract thing is useful for >> this market. Just not these particular ones. The first thing to get >> there is probably an LZMA-based compressor instead of gzip. > > That would need more memory again. >
Actually, even with a 64K dictionary size (for which point the decompression runtime memory requirements are comparable to gzip) LZMA beats both gzip -9 and bzip2 -9 quite handily:
Reference (this is an i386 kernel):
-rwxrwxr-x 1 hpa hpa 5607558 Jul 18 15:04 vmlinux.bin* -rw-rw-r-- 1 hpa hpa 2658275 Jul 18 15:04 vmlinux.bin.bz2 -rw-rw-r-- 1 hpa hpa 2760849 Jul 18 15:04 vmlinux.bin.gz
Pure LZMA with dictionary sizes from 2^16 to 2^24:
-rw-rw-r-- 1 hpa hpa 2380983 Jul 18 15:14 d16.7z -rw-rw-r-- 1 hpa hpa 2317458 Jul 18 15:15 d18.7z -rw-rw-r-- 1 hpa hpa 2284746 Jul 18 15:15 d20.7z -rw-rw-r-- 1 hpa hpa 2264001 Jul 18 15:15 d22.7z -rw-rw-r-- 1 hpa hpa 2263185 Jul 18 15:15 d24.7z
LZMA with BCJ precompression:
-rw-rw-r-- 1 hpa hpa 2236070 Jul 18 15:14 d16bcj.7z -rw-rw-r-- 1 hpa hpa 2167873 Jul 18 15:15 d18bcj.7z -rw-rw-r-- 1 hpa hpa 2134541 Jul 18 15:15 d20bcj.7z -rw-rw-r-- 1 hpa hpa 2112987 Jul 18 15:15 d22bcj.7z -rw-rw-r-- 1 hpa hpa 2111917 Jul 18 15:15 d24bcj.7z
> Better just write less bloated code. Perhaps mandatory bloatometer > runs during -rc*s for kernels with minimal config with public code pig shame lists > similar to the regression lists are useful. Anyone volunteering? > > I suspect there is also much more low hanging fruit of this around.
Most likely.
> I don't think eliminating cpuid is a step forward though; that's > just madness.
Agreed, especially given the invasiveness of the patch.
-hpa - 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/
|  |