FS#25875 - [linux] change from CONFIG_KERNEL_XZ to CONFIG_KERNEL_GZIP
Attached to Project:
Arch Linux
Opened by Tom Gundersen (tomegun) - Saturday, 03 September 2011, 11:35 GMT
Last edited by Tobias Powalowski (tpowa) - Wednesday, 05 October 2011, 08:00 GMT
Opened by Tom Gundersen (tomegun) - Saturday, 03 September 2011, 11:35 GMT
Last edited by Tobias Powalowski (tpowa) - Wednesday, 05 October 2011, 08:00 GMT
|
Details
This was discussed in the past, but no firm conclusion was
reached as far as I understand, so I'm putting it out here
again.
The main concern when choosing the compression algorithm for the kernel image should be boot speed (imho). One could also consider the size of the image, but as the difference in size between the different algorithms is less than one megabyte (I don't have the exact number, but this is certainly an upper bound), I don't think it is worth considering. The slower the hdd speed, the more a machine will benefit from a high compression ratio (as the time it takes to load the kernel will be disk read + decompression). However, even on the machine with the slowest disk I could get my hands on (~35MB/s buffered reads) using gzip is significantly faster than using xz. As was pointed out to me by Thomas, the situation might be different on machines with buggy BIOS'es (where int13h disk access is extremely slow) or when using PXE boot. If the majority of BIOS'es are known to be buggy and it is known that XZ is the better choice in these cases, I guess it should stay as it is. However, if we don't know, then I don't think it makes sense to optimize for this case. |
This task depends upon
Closed by Tobias Powalowski (tpowa)
Wednesday, 05 October 2011, 08:00 GMT
Reason for closing: Fixed
Additional comments about closing: 3.0.6-1
Wednesday, 05 October 2011, 08:00 GMT
Reason for closing: Fixed
Additional comments about closing: 3.0.6-1
As to real time, my estimate is that the savings will be in the hundreds of milliseconds, but I don't know the best way to get the proper numbers. By analogy, I compared the initrd times and there I saved about about 150 ms when switching from xz to gzip. My initrd is about half the size of my kernel, so I guess a couple of hundred milliseconds will not be too far off the mark.
Obviously 200 ms (or whatever it is) will not be noticeable in isolation, but we need to start somewhere. The reason I'm suggesting the change is that gzip seems to be strictly better than xz (unless there is something I'm missing). Is there any reason to stick with xz?
I have been googling this to find out why people might want to choose the different options, but I have not found any compelling arguments either way that apply to us.
In fact, I would expect it even slows things down for PXE on LAN (10MB/s ==> 100ms transfer time saved).
My new laptop has a SSD and decompressing the kernel is visibly (a few hundred milliseconds) the slowest part of the post-bootloader startup process.
CONFIG_KERNEL_GZIP : 2882624
CONFIG_KERNEL_BZIP2 : 2932720
CONFIG_KERNEL_LZMA : 2341616
CONFIG_KERNEL_XZ : 2350128
CONFIG_KERNEL_LZO : 3337136
<---- script to run from the kernel sources root --->
#! /bin/bash
set -eu
comp_methods=( CONFIG_KERNEL_{GZIP,BZIP2,LZMA,XZ,LZO} )
# disable all
for comp_method in ${comp_methods[@]}; do
./scripts/config --disable $comp_method
done
# enable one at a time
for comp_method in ${comp_methods[@]}; do
./scripts/config --enable $comp_method
#diff -u ../../config .config | less
make bzImage >/dev/null 2>&1
size=$(stat -c %s ./arch/x86/boot/bzImage)
printf '%-20s:%8d\n' $comp_method $size
./scripts/config --disable $comp_method
done
XZ makes sense for our packages; not so much as a low-level efficient compression method for time/memory/space-saved, where gzip still seems to be the winner.