From ccf7aa3acbf44d8874cb010687e79bbdd8975acf Mon Sep 17 00:00:00 2001 From: Mikhail Novosyolov Date: Tue, 4 May 2021 15:17:47 +0300 Subject: [PATCH] Add comments about comparing zstd vs xz --- kernel.spec | 41 ++++++++++++++++++++++++++++++++++++++--- 1 file changed, 38 insertions(+), 3 deletions(-) diff --git a/kernel.spec b/kernel.spec index 89f8f80..0b9b483 100644 --- a/kernel.spec +++ b/kernel.spec @@ -32,7 +32,7 @@ %define sublevel 34 # Release number. Increase this before a rebuild. -%define rpmrel 3 +%define rpmrel 7 %define fullrpmrel %{rpmrel} %define rpmtag %{disttag} @@ -105,7 +105,9 @@ # compress modules with zstd (zstd is good compression and fast decompression) %bcond_without compress_modules # Spend more resources on compression, but make resulting size less; -# decompression speed will not be affected. +# decompression speed will not be affected, but more memory will be required +# which should not a problem here (performance penalty from allocating more +# memory should not be big, I think, but I did not benchmark). %define zstd_cmd zstd -q --format=zstd --ultra -22 # Kernel flavour @@ -1467,8 +1469,41 @@ rm -f %{certs_verify_tmp} # compressing modules %if %{with compress_modules} +# Tested on /lib/modules/5.10.34-generic-2rosa2019.1-x86_64, the results are the following: +# * decompressed: 266.3 MiB +# * xz -9 --extreme: 67.8 MiB +# * zstd --ultra -22 without training: 73.5 MiB +# * zstd -6 without training: 79.6 MiB +# * zstd --ultra -22 with training: 66.3 MiB (the winner!) +# Training takes only a few minutes, make it here in place with current zstd and kernel modules. +# But! Decompressing also requires a dictionary for zstd, that will be too complex, so not using training :( +# We already use zstd in dracut to compress initrds quickly and with good compression ration. +# Testing speed of loading modules: +# `time modinfo bcache.ko.xz` took 0,048s, `time modinfo bcache.ko.zstd` took 0,014s (for multiple times) +# find /lib/modules/5.10.34-generic-2rosa2019.1-x86_64 -type f -name '*.ko.zst' > /tmp/zst.list +# time { for i in `cat /tmp/zst.list`; do modinfo $i >/dev/null 2>&1; done ;} +# took ~31-40s, with disk cache (2+ runs) ~33s +# find /lib/modules/5.10.34-generic-1rosa2019.1-x86_64 -type f -name '*.ko.xz' > /tmp/xz.list +# time { for i in `cat /tmp/xz.list`; do modinfo $i >/dev/null 2>&1; done ;} +# took 43-47s, with disk cache (2+ runs) ~42s, +21% +# zstd-compressed initramfs image initrd-5.10.34-generic-1rosa2019.1-x86_64.img with *.ko.xz is 56,3 MiB +# zstd-compressed initramfs image initrd-5.10.34-generic-2rosa2019.1-x86_64.img with *.ko.zst is 58,4 MiB (+3.6%) +# /lib/modules/5.10.34-generic-1rosa2019.1-x86_64 (*.ko.xz) is 78,1 MiB +# /lib/modules/5.10.34-generic-2rosa2019.1-x86_64 (*.ko.zst) is 83,9 MiB (+7%) +# When zstd is compressing cpio (initrd image) with zstd-compressed kernel modules inside it, does it recompress data? +# It is not easy to make a choice between zstd and xz for kernel modules... Disk space (and so speed of installing +# RPM packages) is not much bigger, we do not try to support super low end devices, operation speed is a bit better. +# I have not seen measurable difference in startup time according to systemd-analyze. +# Note that decompression after zstd --ultra -22 will consume more memory than after zstd -6, see commit message in +# https://github.com/torvalds/linux/commit/73f3d1b48f5069d46b. I did not benchmark -6 vs -22 in runtime. +# Let's use zstd for now. +# zstd may also be used to compress linux-firmware to save a lot of space on disk, +# but upstream kernels still cannot decompress it. +#%%{zstd_cmd} -T0 --train $(find . -type f -name '*.ko') +#[ -f dictionary ] # -T1 (one thread) because we run multiple zstd processes by xargs -find %{target_modules} -name "*.ko" | %kxargs %{zstd_cmd} --rm -T1 +find %{target_modules} -name "*.ko" | %kxargs %{zstd_cmd} --rm -T1 #-D dictionary +#rm -f dictionary %endif find %{buildroot}%{_modulesdir} -type f -name '*.ko%{kmod_suffix}' | sed -e 's,^%{buildroot},,' | sort -u >> %{kernel_files}