In a similar kind of exercise, I've been looking at the default
compression for the kernel and how this affects boot speed.
Data:
http://kernel.ubuntu.com/~cking/kernel-boot-speed-vs-compression.ods
(libreoffice spread sheet)
I've tested this on a fairly speedy desktop box and it is interesting to
see that lz4 is blisteringly fast at decompressing the kernel, next is
lzo followed by gzip. xz, lzma and bzip2 are painfully slow in
decompression by comparison.
The trade off is compressed kernel size and hence how much time is
required to load a compressed kernel becomes important. Since gzip
compresses better than lz4 and lzo, one finds that a gzip compressed
kernel booted from a HDD boots slightly faster than lz4 and lzo. Where
as on a moderately fast SSD the faster load speed ends up with lz4 being
marginally faster than lzo and gzip.
So, the "best" kernel compression is hard to split between gzip/lzo/lz4
for a typical SSD based 3.4GHz box, and gzip is probably best for a HDD
based 3.4GHz box. These results will differ on different H/W depending
on CPU speed, drive speed, bus speed and even how fragmented and/or
where the kernel is located on the boot device.
The next variable for me to look at is how CPU speed/architecture
changes boot performance, I hope to get around checking this out on a
Synquacer 24 proc ARM64 box in some time in the near future.
Colin
On 19/03/18 14:59, Balint Reczey wrote:
> Hi,
>
> Initramfs-tools uses gzip compression by default which served us well
> for quite some time but LZ4 offers way faster decompression while
> making a only slightly bigger initramfs files.
>
> On my old laptop the initramfs extraction time decreased from ~1.2s to ~0.24s:
> (with lz4)
> kernel: [ 0.297726] Unpacking initramfs...
> kernel: [ 0.535061] Freeing initrd memory: 77940K
> kernel: [ 0.301637] Unpacking initramfs...
> kernel: [ 0.539109] Freeing initrd memory: 77940K
> (with gzip)
> kernel: [ 0.273748] Unpacking initramfs...
> kernel: [ 1.490066] Freeing initrd memory: 57140K
> kernel: [ 0.281729] Unpacking initramfs...
> kernel: [ 1.498493] Freeing initrd memory: 57140K
>
> The increase in the initrd.img size is ~14%:
> (lz4)
> -rw-r--r-- 1 root root 66709065 márc 19 14:24
> /boot/initrd.img-4.15.0-12-generic
> (gzip)
> -rw-r--r-- 1 root root 58510993 márc 19 12:57
> /boot/initrd.img-4.15.0-12-generic.bak
>
> Initramfs creation speed also improved a bit from ~24s to ~21s wall clock time:
> (lz4)
> update-initramfs: Generating /boot/initrd.img-4.15.0-12-generic
> 14.97user 6.31system 0:20.47elapsed 103%CPU (0avgtext+0avgdata
> 22368maxresident)k
> update-initramfs: Generating /boot/initrd.img-4.15.0-12-generic
> 15.18user 6.49system 0:20.48elapsed 105%CPU (0avgtext+0avgdata
> 22308maxresident)k
> (gzip)
> update-initramfs: Generating /boot/initrd.img-4.15.0-12-generic
> 18.23user 6.77system 0:23.61elapsed 105%CPU (0avgtext+0avgdata
> 22396maxresident)k
> update-initramfs: Generating /boot/initrd.img-4.15.0-12-generic
> 18.38user 6.83system 0:23.82elapsed 105%CPU (0avgtext+0avgdata
> 22292maxresident)k
>
> Base on the results I plan adding LZ4 compression support to
> initramfs-tools as requested in LP: #1488620 [1] in the next days
> without setting it as default and I propose setting LZ4 as default for
> 18.10.
>
> I'm aware of the old problem of /boot filling up with kernels and
> initramfs files but unattended-upgrades already removes old kernels
> [2] and update-manager is planned to do the same starting with 18.04
> [3] thus Ubuntu systems will have enough space in /boot to allow
> slightly bigger initrd files.
>
> Cheers,
> Balint
>
> [1] https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1488620
> [2] https://launchpad.net/ubuntu/+source/unattended-upgrades/1.0ubuntu1
> [3] https://code.launchpad.net/~rbalint/update-manager/remove-autoremovable-kernels/+merge/341599
>
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
