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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/