Activity log for bug #1931725

Date Who What changed Old value New value Message
2021-06-11 15:44:24 Colin Ian King bug added bug
2021-06-11 15:44:24 Colin Ian King attachment added Libreoffice spread sheet with supporting data https://bugs.launchpad.net/bugs/1931725/+attachment/5504114/+files/zstd-vs-lz4-initramfs-kernel-benchmarks.ods
2021-06-11 15:46:09 Colin Ian King description Turns out that loading is always the slow part in loading initramfs into memory, decompression is always the final 10-20% or so of the task. It therefore makes sense to use the a good compressor that shrinks the initramfs as much as possible with little decompression overhead. Benchmarking zstd vs lz4 shows that while zstd can be ~5x slower in decompression the image size is much smaller with zstd than lz4, and since ~80-90% of the boot time is loading the image it makes sense to use zstd. Attached is a libreoffice spread sheet showing typical load and decompression times for a fairly standard 3.4 GHZ intel box with data for load times for a 5400 RPM, 7200 RPM and SATA SSD drives. The conclusions from the test results (attached) show: 1. Loading time is always significantly slower than decompression time. 2. ZSTD is 5x slower than LZ4 in decompression speed but produces far better compressed images 3. Given that loading time is the major factor in loading + decompression, ZSTD is best for kernel and initramfs boot timings. (Also refer to https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3/kernel-compression-method.txt for some raw data on drive load speeds for the same UEFI box I did a couple of years ago). Turns out that loading is always the slow part in loading initramfs into memory and decompressing it since decompression is always the final 10-20% or so of the task. It therefore makes sense to use a good compressor that shrinks the initramfs as much as possible with little decompression overhead. Benchmarking zstd vs lz4 shows that while zstd can be ~5x slower in decompression the image size is much smaller with zstd than lz4, and since ~80-90% of the boot time is loading the image it makes sense to use zstd. Attached is a libreoffice spread sheet showing typical load and decompression times for a fairly standard 3.4 GHZ intel box with data for load times for a 5400 RPM, 7200 RPM and SATA SSD drives. The conclusions from the test results (attached) show: 1. Loading time is always significantly slower than decompression time. 2. ZSTD is 5x slower than LZ4 in decompression speed but produces far better compressed images 3. Given that loading time is the major factor in loading + decompression, ZSTD is best for kernel and initramfs boot timings. (Also refer to https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3/kernel-compression-method.txt for some raw data on drive load speeds for the same UEFI box I did a couple of years ago).
2021-06-11 15:46:29 Colin Ian King description Turns out that loading is always the slow part in loading initramfs into memory and decompressing it since decompression is always the final 10-20% or so of the task. It therefore makes sense to use a good compressor that shrinks the initramfs as much as possible with little decompression overhead. Benchmarking zstd vs lz4 shows that while zstd can be ~5x slower in decompression the image size is much smaller with zstd than lz4, and since ~80-90% of the boot time is loading the image it makes sense to use zstd. Attached is a libreoffice spread sheet showing typical load and decompression times for a fairly standard 3.4 GHZ intel box with data for load times for a 5400 RPM, 7200 RPM and SATA SSD drives. The conclusions from the test results (attached) show: 1. Loading time is always significantly slower than decompression time. 2. ZSTD is 5x slower than LZ4 in decompression speed but produces far better compressed images 3. Given that loading time is the major factor in loading + decompression, ZSTD is best for kernel and initramfs boot timings. (Also refer to https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3/kernel-compression-method.txt for some raw data on drive load speeds for the same UEFI box I did a couple of years ago). Turns out that loading is always the slow part in loading initramfs into memory and decompressing it since decompression is always the final 10-20% or so of the task. It therefore makes sense to use a good compressor that shrinks the initramfs as much as possible with little decompression overhead. Benchmarking zstd vs lz4 shows that while zstd can be ~5x slower in decompression, the image size is much smaller with zstd than lz4, and since ~80-90% of the boot time is loading the image it makes sense to use zstd. Attached is a libreoffice spread sheet showing typical load and decompression times for a fairly standard 3.4 GHZ intel box with data for load times for a 5400 RPM, 7200 RPM and SATA SSD drives. The conclusions from the test results (attached) show: 1. Loading time is always significantly slower than decompression time. 2. ZSTD is 5x slower than LZ4 in decompression speed but produces far better compressed images 3. Given that loading time is the major factor in loading + decompression, ZSTD is best for kernel and initramfs boot timings. (Also refer to https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3/kernel-compression-method.txt for some raw data on drive load speeds for the same UEFI box I did a couple of years ago).
2021-06-11 15:47:23 Colin Ian King bug task added linux (Ubuntu)
2021-06-11 15:47:49 Colin Ian King linux (Ubuntu): assignee Seth Forshee (sforshee)
2021-06-11 15:57:31 Dimitri John Ledkov initramfs-tools (Ubuntu): status New Fix Committed
2021-06-12 11:06:52 Launchpad Janitor initramfs-tools (Ubuntu): status Fix Committed Fix Released
2021-06-15 11:36:55 Dimitri John Ledkov summary initramfs-tools: use zstd as the default compression method initramfs-tools & kernel: use zstd as the default compression method
2021-06-15 11:37:27 Dimitri John Ledkov description Turns out that loading is always the slow part in loading initramfs into memory and decompressing it since decompression is always the final 10-20% or so of the task. It therefore makes sense to use a good compressor that shrinks the initramfs as much as possible with little decompression overhead. Benchmarking zstd vs lz4 shows that while zstd can be ~5x slower in decompression, the image size is much smaller with zstd than lz4, and since ~80-90% of the boot time is loading the image it makes sense to use zstd. Attached is a libreoffice spread sheet showing typical load and decompression times for a fairly standard 3.4 GHZ intel box with data for load times for a 5400 RPM, 7200 RPM and SATA SSD drives. The conclusions from the test results (attached) show: 1. Loading time is always significantly slower than decompression time. 2. ZSTD is 5x slower than LZ4 in decompression speed but produces far better compressed images 3. Given that loading time is the major factor in loading + decompression, ZSTD is best for kernel and initramfs boot timings. (Also refer to https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3/kernel-compression-method.txt for some raw data on drive load speeds for the same UEFI box I did a couple of years ago). Turns out that loading is always the slow part in loading initramfs into memory and decompressing it since decompression is always the final 10-20% or so of the task. It therefore makes sense to use a good compressor that shrinks the initramfs as much as possible with little decompression overhead. Benchmarking zstd vs lz4 shows that while zstd can be ~5x slower in decompression, the image size is much smaller with zstd than lz4, and since ~80-90% of the boot time is loading the image it makes sense to use zstd. Attached is a libreoffice spread sheet showing typical load and decompression times for a fairly standard 3.4 GHZ intel box with data for load times for a 5400 RPM, 7200 RPM and SATA SSD drives. The conclusions from the test results (attached) show: 1. Loading time is always significantly slower than decompression time. 2. ZSTD is 5x slower than LZ4 in decompression speed but produces far better compressed images 3. Given that loading time is the major factor in loading + decompression, ZSTD is best for kernel and initramfs boot timings. (Also refer to https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3/kernel-compression-method.txt for some raw data on drive load speeds for the same UEFI box I did a couple of years ago). amd64 supports zstd, but s390x does not. Will use this bug to enable zstd support on s390x.
2021-06-15 18:08:01 Dimitri John Ledkov description Turns out that loading is always the slow part in loading initramfs into memory and decompressing it since decompression is always the final 10-20% or so of the task. It therefore makes sense to use a good compressor that shrinks the initramfs as much as possible with little decompression overhead. Benchmarking zstd vs lz4 shows that while zstd can be ~5x slower in decompression, the image size is much smaller with zstd than lz4, and since ~80-90% of the boot time is loading the image it makes sense to use zstd. Attached is a libreoffice spread sheet showing typical load and decompression times for a fairly standard 3.4 GHZ intel box with data for load times for a 5400 RPM, 7200 RPM and SATA SSD drives. The conclusions from the test results (attached) show: 1. Loading time is always significantly slower than decompression time. 2. ZSTD is 5x slower than LZ4 in decompression speed but produces far better compressed images 3. Given that loading time is the major factor in loading + decompression, ZSTD is best for kernel and initramfs boot timings. (Also refer to https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3/kernel-compression-method.txt for some raw data on drive load speeds for the same UEFI box I did a couple of years ago). amd64 supports zstd, but s390x does not. Will use this bug to enable zstd support on s390x. Turns out that loading is always the slow part in loading initramfs into memory and decompressing it since decompression is always the final 10-20% or so of the task. It therefore makes sense to use a good compressor that shrinks the initramfs as much as possible with little decompression overhead. Benchmarking zstd vs lz4 shows that while zstd can be ~5x slower in decompression, the image size is much smaller with zstd than lz4, and since ~80-90% of the boot time is loading the image it makes sense to use zstd. Attached is a libreoffice spread sheet showing typical load and decompression times for a fairly standard 3.4 GHZ intel box with data for load times for a 5400 RPM, 7200 RPM and SATA SSD drives. The conclusions from the test results (attached) show: 1. Loading time is always significantly slower than decompression time. 2. ZSTD is 5x slower than LZ4 in decompression speed but produces far better compressed images 3. Given that loading time is the major factor in loading + decompression, ZSTD is best for kernel and initramfs boot timings. (Also refer to https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3/kernel-compression-method.txt for some raw data on drive load speeds for the same UEFI box I did a couple of years ago). amd64 supports zstd, but s390x does not. Will use this bug to enable zstd support on s390x. Upstream submitted patch https://lore.kernel.org/linux-s390/20210615114150.325080-1-dimitri.ledkov@canonical.com/T/#u
2021-06-16 05:43:23 Frank Heimes bug task added ubuntu-z-systems
2021-06-16 05:43:37 Frank Heimes ubuntu-z-systems: assignee bugproxy (bugproxy)
2021-06-16 05:43:51 Frank Heimes tags reverse-proxy-bugzilla s390x
2021-06-16 10:49:37 bugproxy tags reverse-proxy-bugzilla s390x architecture-s39064 bugnameltc-193300 reverse-proxy-bugzilla s390x severity-high targetmilestone-inin2004
2021-07-04 17:42:55 Ubuntu Kernel Bot tags architecture-s39064 bugnameltc-193300 reverse-proxy-bugzilla s390x severity-high targetmilestone-inin2004 architecture-s39064 bugnameltc-193300 reverse-proxy-bugzilla s390x severity-high targetmilestone-inin2004 verification-needed-focal
2021-08-18 07:14:28 Ubuntu Kernel Bot linux (Ubuntu): status New Incomplete
2021-08-18 07:22:59 Frank Heimes tags architecture-s39064 bugnameltc-193300 reverse-proxy-bugzilla s390x severity-high targetmilestone-inin2004 verification-needed-focal architecture-s39064 bot-stop-nagging bugnameltc-193300 reverse-proxy-bugzilla s390x severity-high targetmilestone-inin2004 verification-needed-focal
2021-08-18 07:23:07 Frank Heimes ubuntu-z-systems: status New Fix Released
2021-08-18 23:09:18 Launchpad Janitor linux (Ubuntu): status Incomplete Fix Released
2021-09-02 12:10:30 Krzysztof Kozlowski bug task added linux-oracle (Ubuntu)
2021-09-02 12:11:17 Krzysztof Kozlowski linux-oracle (Ubuntu): status New Fix Committed
2021-10-11 13:12:53 Launchpad Janitor linux-oracle (Ubuntu): status Fix Committed Fix Released
2024-07-22 14:39:51 bugproxy tags architecture-s39064 bot-stop-nagging bugnameltc-193300 reverse-proxy-bugzilla s390x severity-high targetmilestone-inin2004 verification-needed-focal architecture-s39064 bot-stop-nagging bugnameltc-193300 reverse-proxy-bugzilla s390x severity-high targetmilestone-inin2004