Supporting LZ4 as initramfs compressor

Dimitri John Ledkov xnox at ubuntu.com
Wed Jun 5 12:15:48 UTC 2019


On Fri, 31 May 2019 at 09:13, Seth Arnold <seth.arnold at canonical.com> wrote:
>
> On Thu, May 30, 2019 at 11:46:57AM +0100, Dimitri John Ledkov wrote:
> > As if lz4 kernel & xz initrd would yield the fastest boot time? That
>
> I'm lacking some context here, but I think building the initrds is already
> too slow and I'm afraid xz on initrd rebuilds would be significantly
> worse than lz4 or zstd or even low-compression levels of zlib.
>
> Boot times are important but every now and then people do run apt upgrade
> by hand and waiting forever to rebuild an initrd that may or may not be
> used is pretty tedious. xz is great if the really slow compress times will
> be made up for by better transfers or disk savings or similar.
>

I've tried to dig up past benchmarks in private discussions, public
discussions and kernel mailing list.

Zstd patches have not made it into the upstream kernel yet.

As used by mkinitramfs:
- lz4 is faster to compress than gzip
- lz4 is blazingly fast to decompress
- lzma is dog slow to compress and decompress, but is tiny
- lz4 size weight over gzip is marginal (14%) but imho worth the
improved boot time & initrd creation time
- xz is potentially even slower and even smaller than lzma

In places where size is an absolute premium (tiny embedded iot
devices) and performance is irrelevant, xz or lzma should be used.

In all other places, our performance profile is in favor of lz4.

Imho that includes the kernel image itself, thus we should consider switching:
- initramfs tools to default to lz4
- livecd-rootfs to default to lz4
- kernels to compress kernel image with lz4
- grub to include lz4 support

I shall proceed with changing the defaults on the above to improve our
responsiveness experience on installer, cloud, core and classic
devices.
If our firstboot & subsequent boot speed degrades or disk space
becomes a concern, we can look into tweaking these changes further.

-- 
Regards,

Dimitri.



More information about the ubuntu-devel mailing list