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 |
|