Add comments about comparing zstd vs xz

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}