diff options
author | Matthias Schiffer <mschiffer@universe-factory.net> | 2020-05-13 20:33:46 +0200 |
---|---|---|
committer | Matthias Schiffer <mschiffer@universe-factory.net> | 2020-05-31 11:03:31 +0200 |
commit | 4bd7990488b0ca7b5cae16f0a9147a4146759053 (patch) | |
tree | de26803bbf3df9404a7a6af8f72f62416b2b8e4e /scripts/remote-gdb | |
parent | 4696112ea28299a805ef7de5aff32451adfb2fc3 (diff) | |
download | upstream-4bd7990488b0ca7b5cae16f0a9147a4146759053.tar.gz upstream-4bd7990488b0ca7b5cae16f0a9147a4146759053.tar.bz2 upstream-4bd7990488b0ca7b5cae16f0a9147a4146759053.zip |
build: compress kernel debuginfo using zstd
zstd with its default settings (compression level -3) compresses better
than bzip2 -9 (which is the default setting), and is an order of magnitude
faster.
I made the following measurements for the most common compression tools
(all standard Debian Buster versions, default flags unless noted
otherwise), using the debug information of a large x86-64 kernel with
ALL_KMODS:
* kernel-debug.tar: 376M
* kernel-debug.tar.gz: 101M, compressed in ~12s
* kernel-debug.tar.bz2: 91M, compressed in ~15s
* kernel-debug.tar.xz: 57M, compressed in ~101s
* kernel-debug.tar.zst: 86M, compressed in ~1s
With zstd, there is still some room for improvement by increasing the
compression, but the slight increase in compression ratio
(22.83% -> 19.46%) does not justify the significant increase in
compression time (about 5 times on my machine) in my opinion.
Note that multithreaded compression (-T argument) does not affect
reproducibility with zstd.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Diffstat (limited to 'scripts/remote-gdb')
0 files changed, 0 insertions, 0 deletions