zstd has better compression ratio and time consumption balance than zlib/lzo/snappy. When no customized compression method specified in kdump.conf, we will use zstd as the default compression method.
**The test method:
I installed kexec-tools with and without the patch, executing the following command for 4 times, and calculate the averange time:
$ rm -f /boot/initramfs-*kdump.img && time kdumpctl rebuild && \ ls -ail /boot/initramfs-*kdump.img
**The test result:
Bare metal x86_64 machine: dracut with squash module | dracut without sqaush module zlib zstd | zlib zstd real 10.6282 10.1676 | 9.509 10.267 user 9.8932 8.6468 | 10.6028 9.0936 sys 3.523 3.4942 | 2.942 3.0662 | size of | kdump.img 30575616 29236224 | 19247949 17007764
PowerVM hosted ppc64le VM: dracut with squash module | dracut without sqaush module zlib zstd | zlib zstd real 10.6742 10.7572 | 9.7676 10.5722 user 18.754 19.8338 | 20.7932 13.179 sys 1.8358 1.864 | 1.637 1.663 | size of | kdump.img 36917248 35467264 | 21441323 19007108
**discussion
As for the file size of kdump.img, zstd makes a smaller size, which is benificial for kdump kernel limited memory.
As for the time consumption for compression when making kdump.img, zstd doesn't show a clear advance than zlib.
v1 -> v2: Use kdump_get_conf_val() to get dracut_args values of kdump.conf
v2 -> v3: Attached testing benchmark
v3 -> v4: Re-measured and re-attached the testing benchmark of x86_64 and ppc64le. Changed regex '.*[[:space:]]' to '(^|[[:space:]])'
As for the time consumption differences between v3 and v4, I think it is due to v3 was measured on a ppc64le VM. There were I/O performance downgration when other VMs were accessing I/O device at the same time, which I didn't get repetted in v4.
Signed-off-by: Tao Liu ltao@redhat.com --- kdump-lib.sh | 6 ++++++ mkdumprd | 4 ++++ mkfadumprd | 4 ++++ 3 files changed, 14 insertions(+)
diff --git a/kdump-lib.sh b/kdump-lib.sh index e435498..6d668a5 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -443,6 +443,12 @@ is_wdt_active() return 1 }
+have_compression_in_dracut_args() +{ + [[ "$(kdump_get_conf_val dracut_args)" =~ \ + (^|[[:space:]])--(gzip|bzip2|lzma|xz|lzo|lz4|zstd|no-compress|compress)([[:space:]]|$) ]] +} + # If "dracut_args" contains "--mount" information, use it # directly without any check(users are expected to ensure # its correctness). diff --git a/mkdumprd b/mkdumprd index d87d588..9c26ecc 100644 --- a/mkdumprd +++ b/mkdumprd @@ -431,6 +431,10 @@ done <<< "$(kdump_read_conf)"
handle_default_dump_target
+if ! have_compression_in_dracut_args; then + add_dracut_arg "--compress" "zstd" +fi + if [[ -n $extra_modules ]]; then add_dracut_arg "--add-drivers" "$extra_modules" fi diff --git a/mkfadumprd b/mkfadumprd index b890f83..16fdacc 100644 --- a/mkfadumprd +++ b/mkfadumprd @@ -62,6 +62,10 @@ if is_squash_available; then _dracut_isolate_args+=(--add squash) fi
+if ! have_compression_in_dracut_args; then + _dracut_isolate_args+=(--compress zstd) +fi + if ! dracut --force --quiet "${_dracut_isolate_args[@]}" "$@" "$TARGET_INITRD"; then perror_exit "mkfadumprd: failed to setup '$TARGET_INITRD' with dump capture capability" fi
Hi Tao,
On Thu, Dec 30, 2021 at 05:18:03PM +0800, Tao Liu wrote:
zstd has better compression ratio and time consumption balance than
Maybe we should also mention the big advantage of zstd over zlib/lzo/snappy i.e. the decompression is much faster.
zlib/lzo/snappy. When no customized compression method specified in kdump.conf, we will use zstd as the default compression method.
**The test method:
I installed kexec-tools with and without the patch, executing the following command for 4 times, and calculate the averange time:
$ rm -f /boot/initramfs-*kdump.img && time kdumpctl rebuild && \ ls -ail /boot/initramfs-*kdump.img
**The test result:
Bare metal x86_64 machine: dracut with squash module | dracut without sqaush module zlib zstd | zlib zstd real 10.6282 10.1676 | 9.509 10.267 user 9.8932 8.6468 | 10.6028 9.0936 sys 3.523 3.4942 | 2.942 3.0662 | size of | kdump.img 30575616 29236224 | 19247949 17007764
PowerVM hosted ppc64le VM: dracut with squash module | dracut without sqaush module zlib zstd | zlib zstd real 10.6742 10.7572 | 9.7676 10.5722 user 18.754 19.8338 | 20.7932 13.179 sys 1.8358 1.864 | 1.637 1.663 | size of | kdump.img 36917248 35467264 | 21441323 19007108
**discussion
As for the file size of kdump.img, zstd makes a smaller size, which is benificial for kdump kernel limited memory.
As for the time consumption for compression when making kdump.img, zstd doesn't show a clear advance than zlib.
^^^^^^^^^^^^^^^^^^ Should it be "an obvious advantage over"?
v1 -> v2: Use kdump_get_conf_val() to get dracut_args values of kdump.conf
v2 -> v3: Attached testing benchmark
v3 -> v4: Re-measured and re-attached the testing benchmark of x86_64 and ppc64le. Changed regex '.*[[:space:]]' to '(^|[[:space:]])'
As for the time consumption differences between v3 and v4, I think it is due to v3 was measured on a ppc64le VM. There were I/O performance downgration when other VMs were accessing I/O device at the same time, which I didn't get repetted in v4.
Thanks for the clarification! ppc64le VM seems a bit unusual. Even in v4, the user time is much more than the real time which make it looks like the compression uses more than one thread.
Signed-off-by: Tao Liu ltao@redhat.com
kdump-lib.sh | 6 ++++++ mkdumprd | 4 ++++ mkfadumprd | 4 ++++ 3 files changed, 14 insertions(+)
diff --git a/kdump-lib.sh b/kdump-lib.sh index e435498..6d668a5 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -443,6 +443,12 @@ is_wdt_active() return 1 }
+have_compression_in_dracut_args() +{
- [[ "$(kdump_get_conf_val dracut_args)" =~ \
(^|[[:space:]])--(gzip|bzip2|lzma|xz|lzo|lz4|zstd|no-compress|compress)([[:space:]]|$) ]]
+}
# If "dracut_args" contains "--mount" information, use it # directly without any check(users are expected to ensure # its correctness). diff --git a/mkdumprd b/mkdumprd index d87d588..9c26ecc 100644 --- a/mkdumprd +++ b/mkdumprd @@ -431,6 +431,10 @@ done <<< "$(kdump_read_conf)"
handle_default_dump_target
+if ! have_compression_in_dracut_args; then
- add_dracut_arg "--compress" "zstd"
+fi
if [[ -n $extra_modules ]]; then add_dracut_arg "--add-drivers" "$extra_modules" fi diff --git a/mkfadumprd b/mkfadumprd index b890f83..16fdacc 100644 --- a/mkfadumprd +++ b/mkfadumprd @@ -62,6 +62,10 @@ if is_squash_available; then _dracut_isolate_args+=(--add squash) fi
+if ! have_compression_in_dracut_args; then
- _dracut_isolate_args+=(--compress zstd)
+fi
if ! dracut --force --quiet "${_dracut_isolate_args[@]}" "$@" "$TARGET_INITRD"; then perror_exit "mkfadumprd: failed to setup '$TARGET_INITRD' with dump capture capability" fi -- 2.33.1
Hi Coiby,
On Fri, Dec 31, 2021 at 11:25 AM Coiby Xu coxu@redhat.com wrote:
Hi Tao,
On Thu, Dec 30, 2021 at 05:18:03PM +0800, Tao Liu wrote:
zstd has better compression ratio and time consumption balance than
Maybe we should also mention the big advantage of zstd over zlib/lzo/snappy i.e. the decompression is much faster.
I can attach the lzo/snappy benchmark results in v5 as well. However it is a bit difficult to measure the decompression time consumption, because it happens in the 2nd kernel boot up period. The string which indicates the start of the decompression initrd is like "Unpacking initramfs...", but it doesn't have a clear string indicating the end of the decompression, unless hacking the kernel to insert an end-string after decompression finishes. Currently I don't have enough time to do that.
zlib/lzo/snappy. When no customized compression method specified in kdump.conf, we will use zstd as the default compression method.
**The test method:
I installed kexec-tools with and without the patch, executing the following command for 4 times, and calculate the averange time:
$ rm -f /boot/initramfs-*kdump.img && time kdumpctl rebuild && \ ls -ail /boot/initramfs-*kdump.img
**The test result:
Bare metal x86_64 machine: dracut with squash module | dracut without sqaush module zlib zstd | zlib zstd real 10.6282 10.1676 | 9.509 10.267 user 9.8932 8.6468 | 10.6028 9.0936 sys 3.523 3.4942 | 2.942 3.0662 | size of | kdump.img 30575616 29236224 | 19247949 17007764
PowerVM hosted ppc64le VM: dracut with squash module | dracut without sqaush module zlib zstd | zlib zstd real 10.6742 10.7572 | 9.7676 10.5722 user 18.754 19.8338 | 20.7932 13.179 sys 1.8358 1.864 | 1.637 1.663 | size of | kdump.img 36917248 35467264 | 21441323 19007108
**discussion
As for the file size of kdump.img, zstd makes a smaller size, which is benificial for kdump kernel limited memory.
As for the time consumption for compression when making kdump.img, zstd doesn't show a clear advance than zlib.
^^^^^^^^^^^^^^^^^^
Should it be "an obvious advantage over"?
For bare metal x86_64 machine, zstd user time decrease for ~1s, sys time increase for ~0.03s For PowerVM hosted ppc64le VM, zstd user time varies for +1s ~ -7s, sys time increase for ~0.03s
I say "doesn't show a clear advance", meaning the time 1s may not be obviously observable to users. I will make a lzo/snappy benchmark test, please wait for a while.
v1 -> v2: Use kdump_get_conf_val() to get dracut_args values of kdump.conf
v2 -> v3: Attached testing benchmark
v3 -> v4: Re-measured and re-attached the testing benchmark of x86_64 and ppc64le. Changed regex '.*[[:space:]]' to '(^|[[:space:]])'
As for the time consumption differences between v3 and v4, I think it is due to v3 was measured on a ppc64le VM. There were I/O performance downgration when other VMs were accessing I/O device at the same time, which I didn't get repetted in v4.
Thanks for the clarification! ppc64le VM seems a bit unusual. Even in v4, the user time is much more than the real time which make it looks like the compression uses more than one thread.
Yes, exactly.
Thanks, Tao Liu
Signed-off-by: Tao Liu ltao@redhat.com
kdump-lib.sh | 6 ++++++ mkdumprd | 4 ++++ mkfadumprd | 4 ++++ 3 files changed, 14 insertions(+)
diff --git a/kdump-lib.sh b/kdump-lib.sh index e435498..6d668a5 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -443,6 +443,12 @@ is_wdt_active() return 1 }
+have_compression_in_dracut_args() +{
[[ "$(kdump_get_conf_val dracut_args)" =~ \
(^|[[:space:]])--(gzip|bzip2|lzma|xz|lzo|lz4|zstd|no-compress|compress)([[:space:]]|$) ]]
+}
# If "dracut_args" contains "--mount" information, use it # directly without any check(users are expected to ensure # its correctness). diff --git a/mkdumprd b/mkdumprd index d87d588..9c26ecc 100644 --- a/mkdumprd +++ b/mkdumprd @@ -431,6 +431,10 @@ done <<< "$(kdump_read_conf)"
handle_default_dump_target
+if ! have_compression_in_dracut_args; then
add_dracut_arg "--compress" "zstd"
+fi
if [[ -n $extra_modules ]]; then add_dracut_arg "--add-drivers" "$extra_modules" fi diff --git a/mkfadumprd b/mkfadumprd index b890f83..16fdacc 100644 --- a/mkfadumprd +++ b/mkfadumprd @@ -62,6 +62,10 @@ if is_squash_available; then _dracut_isolate_args+=(--add squash) fi
+if ! have_compression_in_dracut_args; then
_dracut_isolate_args+=(--compress zstd)
+fi
if ! dracut --force --quiet "${_dracut_isolate_args[@]}" "$@" "$TARGET_INITRD"; then perror_exit "mkfadumprd: failed to setup '$TARGET_INITRD' with dump capture capability" fi -- 2.33.1
-- Best regards, Coiby
On Fri, Dec 31, 2021 at 02:42:17PM +0800, Tao Liu wrote:
Hi Coiby,
On Fri, Dec 31, 2021 at 11:25 AM Coiby Xu coxu@redhat.com wrote:
Hi Tao,
On Thu, Dec 30, 2021 at 05:18:03PM +0800, Tao Liu wrote:
zstd has better compression ratio and time consumption balance than
Maybe we should also mention the big advantage of zstd over zlib/lzo/snappy i.e. the decompression is much faster.
I can attach the lzo/snappy benchmark results in v5 as well. However it is a bit difficult to measure the decompression time consumption, because it happens in the 2nd kernel boot up period. The string which indicates the start of the decompression initrd is like "Unpacking initramfs...", but it doesn't have a clear string indicating the end of the decompression, unless hacking the kernel to insert an end-string after decompression finishes. Currently I don't have enough time to do that.
Yes, measuring the time could in the 2nd kernel could too much hassle. Maybe collecting the data by running zstd directly is sufficient.
zlib/lzo/snappy. When no customized compression method specified in kdump.conf, we will use zstd as the default compression method.
**The test method:
I installed kexec-tools with and without the patch, executing the following command for 4 times, and calculate the averange time:
$ rm -f /boot/initramfs-*kdump.img && time kdumpctl rebuild && \ ls -ail /boot/initramfs-*kdump.img
**The test result:
Bare metal x86_64 machine: dracut with squash module | dracut without sqaush module zlib zstd | zlib zstd real 10.6282 10.1676 | 9.509 10.267 user 9.8932 8.6468 | 10.6028 9.0936 sys 3.523 3.4942 | 2.942 3.0662 | size of | kdump.img 30575616 29236224 | 19247949 17007764
PowerVM hosted ppc64le VM: dracut with squash module | dracut without sqaush module zlib zstd | zlib zstd real 10.6742 10.7572 | 9.7676 10.5722 user 18.754 19.8338 | 20.7932 13.179 sys 1.8358 1.864 | 1.637 1.663 | size of | kdump.img 36917248 35467264 | 21441323 19007108
**discussion
As for the file size of kdump.img, zstd makes a smaller size, which is benificial for kdump kernel limited memory.
As for the time consumption for compression when making kdump.img, zstd doesn't show a clear advance than zlib.
^^^^^^^^^^^^^^^^^^
Should it be "an obvious advantage over"?
For bare metal x86_64 machine, zstd user time decrease for ~1s, sys time increase for ~0.03s For PowerVM hosted ppc64le VM, zstd user time varies for +1s ~ -7s, sys time increase for ~0.03s
I say "doesn't show a clear advance", meaning the time 1s may not be obviously observable to users.
Thanks for the explanation. I haven't seen this phrase "a clear advance" before. Maybe a different phrase should be used.
I will make a lzo/snappy benchmark test, please wait for a while.
v1 -> v2: Use kdump_get_conf_val() to get dracut_args values of kdump.conf
v2 -> v3: Attached testing benchmark
v3 -> v4: Re-measured and re-attached the testing benchmark of x86_64 and ppc64le. Changed regex '.*[[:space:]]' to '(^|[[:space:]])'
As for the time consumption differences between v3 and v4, I think it is due to v3 was measured on a ppc64le VM. There were I/O performance downgration when other VMs were accessing I/O device at the same time, which I didn't get repetted in v4.
Thanks for the clarification! ppc64le VM seems a bit unusual. Even in v4, the user time is much more than the real time which make it looks like the compression uses more than one thread.
Yes, exactly.
Thanks, Tao Liu
Signed-off-by: Tao Liu ltao@redhat.com
kdump-lib.sh | 6 ++++++ mkdumprd | 4 ++++ mkfadumprd | 4 ++++ 3 files changed, 14 insertions(+)
diff --git a/kdump-lib.sh b/kdump-lib.sh index e435498..6d668a5 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -443,6 +443,12 @@ is_wdt_active() return 1 }
+have_compression_in_dracut_args() +{
[[ "$(kdump_get_conf_val dracut_args)" =~ \
(^|[[:space:]])--(gzip|bzip2|lzma|xz|lzo|lz4|zstd|no-compress|compress)([[:space:]]|$) ]]
+}
# If "dracut_args" contains "--mount" information, use it # directly without any check(users are expected to ensure # its correctness). diff --git a/mkdumprd b/mkdumprd index d87d588..9c26ecc 100644 --- a/mkdumprd +++ b/mkdumprd @@ -431,6 +431,10 @@ done <<< "$(kdump_read_conf)"
handle_default_dump_target
+if ! have_compression_in_dracut_args; then
add_dracut_arg "--compress" "zstd"
+fi
if [[ -n $extra_modules ]]; then add_dracut_arg "--add-drivers" "$extra_modules" fi diff --git a/mkfadumprd b/mkfadumprd index b890f83..16fdacc 100644 --- a/mkfadumprd +++ b/mkfadumprd @@ -62,6 +62,10 @@ if is_squash_available; then _dracut_isolate_args+=(--add squash) fi
+if ! have_compression_in_dracut_args; then
_dracut_isolate_args+=(--compress zstd)
+fi
if ! dracut --force --quiet "${_dracut_isolate_args[@]}" "$@" "$TARGET_INITRD"; then perror_exit "mkfadumprd: failed to setup '$TARGET_INITRD' with dump capture capability" fi -- 2.33.1
-- Best regards, Coiby
On Fri, Dec 31, 2021 at 03:48:25PM +0800, Coiby Xu wrote:
On Fri, Dec 31, 2021 at 02:42:17PM +0800, Tao Liu wrote:
Hi Coiby,
[...]
As for the file size of kdump.img, zstd makes a smaller size, which is benificial for kdump kernel limited memory.
As for the time consumption for compression when making kdump.img, zstd doesn't show a clear advance than zlib.
^^^^^^^^^^^^^^^^^^
Should it be "an obvious advantage over"?
For bare metal x86_64 machine, zstd user time decrease for ~1s, sys time increase for ~0.03s For PowerVM hosted ppc64le VM, zstd user time varies for +1s ~ -7s, sys time increase for ~0.03s
I say "doesn't show a clear advance", meaning the time 1s may not be obviously observable to users.
Thanks for the explanation. I haven't seen this phrase "a clear advance" before. Maybe a different phrase should be used.
How about "the users may be oblivious to the change"?
On Fri, Dec 31, 2021 at 4:15 PM Coiby Xu coxu@redhat.com wrote:
On Fri, Dec 31, 2021 at 03:48:25PM +0800, Coiby Xu wrote:
On Fri, Dec 31, 2021 at 02:42:17PM +0800, Tao Liu wrote:
Hi Coiby,
[...]
As for the file size of kdump.img, zstd makes a smaller size, which is benificial for kdump kernel limited memory.
As for the time consumption for compression when making kdump.img, zstd doesn't show a clear advance than zlib.
^^^^^^^^^^^^^^^^^^
Should it be "an obvious advantage over"?
For bare metal x86_64 machine, zstd user time decrease for ~1s, sys time increase for ~0.03s For PowerVM hosted ppc64le VM, zstd user time varies for +1s ~ -7s, sys time increase for ~0.03s
I say "doesn't show a clear advance", meaning the time 1s may not be obviously observable to users.
Thanks for the explanation. I haven't seen this phrase "a clear advance" before. Maybe a different phrase should be used.
How about "the users may be oblivious to the change"?
OK, I will rephrase it in the v5 patch.
Thanks, Tao Liu
-- Best regards, Coiby