Thursday 30 May 2019

Re: Supporting LZ4 as initramfs compressor

Hey,

On Fri, 24 Aug 2018 at 14:11, Colin Ian King <colin.king@canonical.com> wrote:
>
> Hi,
>
> In a similar kind of exercise, I've been looking at the default
> compression for the kernel and how this affects boot speed.
>
> Data:
> http://kernel.ubuntu.com/~cking/kernel-boot-speed-vs-compression.ods
> (libreoffice spread sheet)
>
> I've tested this on a fairly speedy desktop box and it is interesting to
> see that lz4 is blisteringly fast at decompressing the kernel, next is
> lzo followed by gzip. xz, lzma and bzip2 are painfully slow in
> decompression by comparison.
>
> The trade off is compressed kernel size and hence how much time is
> required to load a compressed kernel becomes important. Since gzip
> compresses better than lz4 and lzo, one finds that a gzip compressed
> kernel booted from a HDD boots slightly faster than lz4 and lzo. Where
> as on a moderately fast SSD the faster load speed ends up with lz4 being
> marginally faster than lzo and gzip.
>
> So, the "best" kernel compression is hard to split between gzip/lzo/lz4
> for a typical SSD based 3.4GHz box, and gzip is probably best for a HDD
> based 3.4GHz box. These results will differ on different H/W depending
> on CPU speed, drive speed, bus speed and even how fragmented and/or
> where the kernel is located on the boot device.
>
> The next variable for me to look at is how CPU speed/architecture
> changes boot performance, I hope to get around checking this out on a
> Synquacer 24 proc ARM64 box in some time in the near future.
>

I see a lot of code in livecd-rootfs that tries hard to use lzma
compression for the initaller (first-boot) initrd.
On the classic, subsequent initrds get rebuild as gzip, and on core
lzma persists.
I do wonder what compression we should use by default for the
installer media, Ubuntu Core, cloud images.

Is the rationale for lzma installer initrds still valid? And what was
it? Smallest size initrd?


> Colin
>
>
> On 19/03/18 14:59, Balint Reczey wrote:
> > Hi,
> >
> > Initramfs-tools uses gzip compression by default which served us well
> > for quite some time but LZ4 offers way faster decompression while
> > making a only slightly bigger initramfs files.
> >
> > On my old laptop the initramfs extraction time decreased from ~1.2s to ~0.24s:
> > (with lz4)
> > kernel: [ 0.297726] Unpacking initramfs...
> > kernel: [ 0.535061] Freeing initrd memory: 77940K
> > kernel: [ 0.301637] Unpacking initramfs...
> > kernel: [ 0.539109] Freeing initrd memory: 77940K
> > (with gzip)
> > kernel: [ 0.273748] Unpacking initramfs...
> > kernel: [ 1.490066] Freeing initrd memory: 57140K
> > kernel: [ 0.281729] Unpacking initramfs...
> > kernel: [ 1.498493] Freeing initrd memory: 57140K
> >
> > The increase in the initrd.img size is ~14%:
> > (lz4)
> > -rw-r--r-- 1 root root 66709065 márc 19 14:24
> > /boot/initrd.img-4.15.0-12-generic
> > (gzip)
> > -rw-r--r-- 1 root root 58510993 márc 19 12:57
> > /boot/initrd.img-4.15.0-12-generic.bak
> >
> > Initramfs creation speed also improved a bit from ~24s to ~21s wall clock time:
> > (lz4)
> > update-initramfs: Generating /boot/initrd.img-4.15.0-12-generic
> > 14.97user 6.31system 0:20.47elapsed 103%CPU (0avgtext+0avgdata
> > 22368maxresident)k
> > update-initramfs: Generating /boot/initrd.img-4.15.0-12-generic
> > 15.18user 6.49system 0:20.48elapsed 105%CPU (0avgtext+0avgdata
> > 22308maxresident)k
> > (gzip)
> > update-initramfs: Generating /boot/initrd.img-4.15.0-12-generic
> > 18.23user 6.77system 0:23.61elapsed 105%CPU (0avgtext+0avgdata
> > 22396maxresident)k
> > update-initramfs: Generating /boot/initrd.img-4.15.0-12-generic
> > 18.38user 6.83system 0:23.82elapsed 105%CPU (0avgtext+0avgdata
> > 22292maxresident)k
> >
> > Base on the results I plan adding LZ4 compression support to
> > initramfs-tools as requested in LP: #1488620 [1] in the next days
> > without setting it as default and I propose setting LZ4 as default for
> > 18.10.
> >
> > I'm aware of the old problem of /boot filling up with kernels and
> > initramfs files but unattended-upgrades already removes old kernels
> > [2] and update-manager is planned to do the same starting with 18.04
> > [3] thus Ubuntu systems will have enough space in /boot to allow
> > slightly bigger initrd files.
> >
> > Cheers,
> > Balint
> >
> > [1] https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1488620
> > [2] https://launchpad.net/ubuntu/+source/unattended-upgrades/1.0ubuntu1
> > [3] https://code.launchpad.net/~rbalint/update-manager/remove-autoremovable-kernels/+merge/341599
> >
>
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

--
Regards,

Dimitri.

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