Hi Jann, On Tue, 21 Jan 2025 at 23:16, Jann Horn <jannh@xxxxxxxxxx> wrote: > > Support storing the kernel uncompressed for developers who want to quickly > iterate with one-off kernel builds. > Store it in the usual format with a 4-byte length suffix and keep this new > codepath as close as possible to the normal path where decompression > happens. > > The other compression methods offered by the kernel take some time; > even LZ4 (which the kernel uses at compression level 9) takes ~2.8 > seconds to compress a 110M large vmlinux.bin on my machine. > > An alternate approach to this would be to offer customization of the LZ4 > compression level through a kconfig variable; and yet another approach > would be to abuse the existing gzip decompression logic by storing the > kernel as "non-compressed" DEFLATE blocks, so that the decompression code > will essentially end up just doing a bunch of memcpy() calls. > This all seems pretty complicated, and adding yet another (pseudo-)compression method is not great in terms of maintenance burden, especially because there are other consumers of the compressed images (both for bzImage and EFI zboot) Did you try running gzip with -1 instead of -9? On my build machine, this reduces the compression time of a defconfig bzImage build from 4.3 seconds to 0.9 seconds.
