Thursday 30 May 2019

Re: Supporting LZ4 as initramfs compressor

On Thu, 30 May 2019, Dimitri John Ledkov wrote:
> On Thu, 30 May 2019 at 11:35, Dimitri John Ledkov <xnox@ubuntu.com> wrote:
> > On Fri, 24 Aug 2018 at 14:11, Colin Ian King <colin.king@canonical.com> wrote:
> > > http://kernel.ubuntu.com/~cking/kernel-boot-speed-vs-compression.ods
> > Is the rationale for lzma installer initrds still valid?
> gzip is fast at kernel, but not initrd
> lzma fast at initrd, but not kernel

Colin: would it be possible to re-run the statistics with a control
group (uncompressed kernel; uncompressed initramfs.cpio); this should
show the baseline I/O limits.

A second useful control, would be gzip/zlib in store-only mode
(0% compression): this would give a baseline for the overhead of
loading the data and running it via the decompression chain.

With those two baselines as a starting point; there are space (I/O,
storage) vs. time (load time, decode line) trade-offs---and
probably several local maxima.

> Measurements until break=bottom is reached would be nice.

Gzip/zlib is relatively well-understood stream protocol with literal
(raw data), LZ (lookback/string/matching), and Huffman (bit
squeezing).

Similiar to eg. MPEG, there is quite a bit of flexibility while
still being backwards compatible: multiple encoder and
decoders implementation, quite including hardware support.

It's only a hunch, but suspect that any speed goals can probably be
met with the existing Gzip/zlib; if not something is wrong(tm) or
sub-optimal somewhere.

(See the kernel decompression timing graph).

-Paul


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel