Hi Sedat, all,
The mixed quoting is confusing me a bit, hopefully not to the point
where I miss some questions.
On Thu, 25 Jul 2024 at 21:00, Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote:
>
> On Thu, Jul 25, 2024 at 9:23 PM Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote:
> >
> > dileks@iniza:~/src/linux/git$ git grep zstd scripts/ | egrep '\-(19|22|T0)'
> > scripts/Makefile.lib: cmd_zstd = cat $(real-prereqs) | $(ZSTD) -19 > $@
> > scripts/Makefile.lib: cmd_zstd22 = cat $(real-prereqs) | $(ZSTD)
> > -22 --ultra > $@
> > scripts/Makefile.lib: cmd_zstd22_with_size = { cat
> > $(real-prereqs) | $(ZSTD) -22 --ultra; $(size_append); } > $@
> > scripts/Makefile.modinst: cmd_zstd = $(ZSTD) -T0 --rm -f -q $<
> >
> > -sed@-
> >
> > On Thu, Jul 25, 2024 at 9:09 PM Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote:
> > >
> > > Hi,
> > >
> > > I am a big fan of ZSTD - here version 1.5.6 on Debian/unstable AMD64.
> > >
> > > When playing with CONFIG_MODULE_COMPRESS_ZSTD=y I observed a 35MiB
> > > greater linux-image Debian file.
> > >
> > > Debian: ~100MiB <--- CONFIG_MODULE_COMPRESS_XZ=y
> > > Selfmade: ~135MiB <--- CONFIG_MODULE_COMPRESS_ZSTD=y
> > >
> > > So, I checked the used compression-level of ZSTD in the build-process:
> > >
> > > [ vmlinux.bin.zst ]
> > > $ grep zstd build-log_6.10.1-1-amd64-clang18-kcfi.txt | grep vmlinux.bin.zst
> > > { cat arch/x86/boot/compressed/vmlinux.bin
> > > arch/x86/boot/compressed/vmlinux.relocs | zstd -22 --ultra; printf
> > > \370\040\157\003; } > arch/x86/boot/compressed/vmlinux.
> > > bin.zst
> > >
> > > [ amdgpu.ko.zst ]
> > > $ grep zstd build-log_6.10.1-1-amd64-clang18-kcfi.txt | grep '\-T0' |
> > > grep amdgpu
> > > zstd -T0 --rm -f -q
> > > debian/linux-image-6.10.1-1-amd64-clang18-kcfi/lib/modules/6.10.1-1-amd64-clang18-kcfi/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko
> > >
> > > Here some numbers:
> > >
> > > [ Values in KiB ]
> > > $ du -k amdgpu.ko*
> > > 29264 amdgpu.ko
> > > 5672 amdgpu.ko.zst <--- XXX: -T0
> > > 4264 amdgpu.ko.zst_T0-19 <--- XXX: -T0 -19
> > > 4260 amdgpu.ko.zst_T0-22
> > > 4308 amdgpu.ko.zst_T0-22-ultra
> > >
> > > $ time zstd -T0 -v amdgpu.ko
> > > *** Zstandard CLI (64-bit) v1.5.6, by Yann Collet ***
> > > Note: 2 physical core(s) detected
> > > zstd: amdgpu.ko.zst already exists; overwrite (y/n) ? y
> > > amdgpu.ko : 19.38% ( 28.6 MiB => 5.54 MiB, amdgpu.ko.zst)
> > >
> > > real 0m2,496s
> > > user 0m0,448s
> > > sys 0m0,064s
> > >
> > > $ time zstd -T0 -19 -v amdgpu.ko
> > > *** Zstandard CLI (64-bit) v1.5.6, by Yann Collet ***
> > > Note: 2 physical core(s) detected
> > > amdgpu.ko : 14.56% ( 28.6 MiB => 4.16 MiB, amdgpu.ko.zst)
> > >
> > > real 0m22,821s
> > > user 0m22,759s
> > > sys 0m0,080s
> > >
> > > My wish is to use the zstd-option "-T0" (see vmlinux.bin.zst) everywhere.
> > >
> > > For CONFIG_MODULE_COMPRESS_ZSTD=y: Add compress-level = -19
> > >
> > > NOTE: -22 w/ or w/o ultra has no big effect here and increases even
> > > more build-time.
> > >
> > > What do you think?
> > >
> > > Thanks.
> > >
> > > Best regards,
> > > -Sedat-
>
> [ Adding some more folks - kmod / authors of commit c3d7ef377eb2
> ("kbuild: add support for zstd compressed modules") ]
>
> Debian/unstable AMD54 ships kmod version 32+20240611-1.
>
> To use better/higher ZSTD compression-level for
> CONFIG_MODULE_COMPRESS_ZSTD=y - do we need a newer KMOD version?
>
> DIFF for Linux-6.10.1:
>
> $ git diff scripts/Makefile.modinst
> diff --git a/scripts/Makefile.modinst b/scripts/Makefile.modinst
> index 0afd75472679..2a8b37c80cbf 100644
> --- a/scripts/Makefile.modinst
> +++ b/scripts/Makefile.modinst
> @@ -146,7 +146,7 @@ quiet_cmd_gzip = GZIP $@
> quiet_cmd_xz = XZ $@
> cmd_xz = $(XZ) --check=crc32 --lzma2=dict=1MiB -f $<
> quiet_cmd_zstd = ZSTD $@
> - cmd_zstd = $(ZSTD) -T0 --rm -f -q $<
> + cmd_zstd = $(ZSTD) -T0 -19 --rm -f -q $<
>
> $(dst)/%.ko.gz: $(dst)/%.ko FORCE
> $(call cmd,gzip)
>
The compression tools (zstd, xz, etc) are used predominantly for two
separate topics - kernel image and kernel module compression.
Off the top of my head: in the former case, reasonable compression is
used by all tools. Be that zstd, lzo, lzma, you name it.
Honestly I don't know why and what's the merit behind the levels chosen.
In the modules case, things are also consistent where the default
compression level is used throughout.
Here it makes sense to keep the default since you can consider that
the decompression can be done by either kernel or user-space. Where
each comes with it's limitations:
The in-kernel one does not support ultra levels for zstd (or it used
to at some point) IIRC. The kmod tools themselves rely on the zstd
library liked in, although if one is using busybox then zstd
compressed modules were not supported last time I checked (a year or
so ago).
So for example: you can have zstd --22 modules, if the kernel + kmod
are new enough (have in-kernel decompression) things will fail. If
they're not, things will work just fine.
Which is why, I think it's up-to your distro/builder to choose the
policy. Here is what we've been using In Arch `ZSTD_CLEVEL=19 make ...
modules_install`.
Tl:Dr: You'd want to use `ZSTD_CLEVEL` (or equivalent if using xz)
during make modules_install **depending** on the components used and
their version.
HTH
Emil
