[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 10 Oct 2017 14:55:10 -0700
From: hpa@...or.com
To: Nick Terrell <terrelln@...com>
CC: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
x86@...nel.org, kernel-team@...com, Chris Mason <clm@...com>,
Yann Collet <cyan@...com>, Rene Rebe <rene@...ctcode.com>
Subject: Re: [PATCH 0/2] Add support for ZSTD-compressed kernel
On October 10, 2017 2:22:42 PM PDT, Nick Terrell <terrelln@...com> wrote:
>Hi,
>
>This patch set adds support for a ZSTD-compressed kernel and ramdisk
>images in the kernel boot process. It only integrates the support with
>x86, though the first patch is generic to all architectures.
>
>Zstandard requires slightly more memory during the kernel decompression
>on x86 (192 KB vs 64 KB), and the memory usage is independent of the
>window size.
>
>Zstandard requires memory proprortional to the window size used during
>compression for decompressing the ramdisk image, since streaming mode
>is
>used. Newer versions of zstd (1.3.2+) list the window size of a file
>with `zstd -lv <file>'. The absolute maximum amount of memory required
>is just over 8 MB.
>
>Thanks,
>Nick Terrell
>
>Nick Terrell (2):
> lib: Add support for ZSTD-compressed kernel
> x86: Add support for ZSTD-compressed kernel
>
> Documentation/x86/boot.txt | 6 +-
> arch/x86/Kconfig | 1 +
> arch/x86/boot/compressed/Makefile | 5 +-
> arch/x86/boot/compressed/misc.c | 4 +
> arch/x86/boot/header.S | 8 +-
> arch/x86/include/asm/boot.h | 6 +-
> include/linux/decompress/unzstd.h | 26 +++
> init/Kconfig | 14 +-
> lib/Kconfig | 4 +
> lib/Makefile | 1 +
> lib/decompress.c | 5 +
>lib/decompress_unzstd.c | 341
>++++++++++++++++++++++++++++++++++++++
> lib/xxhash.c | 21 ++-
> lib/zstd/decompress.c | 2 +
> lib/zstd/fse_decompress.c | 9 +-
> scripts/Makefile.lib | 15 ++
> usr/Kconfig | 22 +++
> 17 files changed, 465 insertions(+), 25 deletions(-)
> create mode 100644 include/linux/decompress/unzstd.h
> create mode 100644 lib/decompress_unzstd.c
And, pray tell, what are the actual results? What is the trade-off of kernel size versus decompression performance versus the other algorithms that we already support? Adding algorithms for their own sake is a bad thing not a good thing.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Powered by blists - more mailing lists