[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a6d347be-efdf-4cd8-b43a-5179a58b6e72@mailbox.org>
Date: Wed, 22 Jan 2025 15:52:23 +0100
From: Tor Vic <torvic9@...lbox.org>
To: Jann Horn <jannh@...gle.com>
Cc: Ard Biesheuvel <ardb@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>, Masahiro Yamada <masahiroy@...nel.org>,
Nathan Chancellor <nathan@...nel.org>, Nicolas Schier <nicolas@...sle.eu>,
linux-efi@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>,
linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] x86: Add CONFIG_KERNEL_UNCOMPRESSED support
On 1/22/25 15:30, Jann Horn wrote:
>>
>> Hello,
>>
>> In my opinion 'lz4 -9' doesn't make much sense.
>> It's terribly slow and the compression ratio is also not exactly good.
>>
>> Instead, zstd seems to be a much better choice. Not quite as ultra fast
>> as lz4 levels 1 to 3, but much better compression.
>
> I think you're describing a slightly different usecase.
>
> My goal here is something I can use for when I build a kernel, boot it
> in QEMU, test something, and then immediately throw the kernel away -
> I don't care that much how much disk space the kernel image uses, and
> the goal I'm optimizing for is pretty much just the time needed for
> one build followed by one boot.
Ah, yes, fair enough. In that case, 'lz4 -1' makes the most sense I
guess. Sorry for the noise.
Tor
Powered by blists - more mailing lists