** Description changed:

  Use `lz4 -9 -l` compression for initramfs by default as discussed on
  ubuntu-devel.
  
  This would also pull the lz4 package into main
  
  https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040726.html
  
  [Regression Potential]
  
  We are trying to optimize for total boot speed, but performing a micro-
  optimization upon time to create/unpack kernel/initrd is an insufficient
  benchmark for total boot speed. This is because it ignores time to load
  the kernel/initrd, and whether the firmware/bootloader were able to
  stream decompress it whilst loading it. I.e. it is argued that in the
  real world, subsecond decompression gains are irrelevant if UEFI
  firmware, tftp boot, etc. take a lot longer than that to read extra 10s
  of MBs of boot material.
  
  [TODO]
  Measure pure i/o load speed with stopwatch, to figure out MB/s speed of 
loading initrds/kernel off FAT32, EXT4, TFTP, HTTP.
  Re-evaluate if we should provide different compression mechanisms:
  - ie. gzip instead of lz4 for most cases (revert)
  - ie. xz for painful i/o cases (e.g. netboot)
+ 
+ I booted grub2 and measured loading largish amount of files, ie. $ date;
+ initrd (hd0,gpt5)/initrd.img;  initrd (hd0,gpt5)/initrd.img; initrd
+ (hd0,gpt5)/initrd.img; initrd (hd0,gpt5)/initrd.img; initrd
+ (hd0,gpt5)/initrd.img; date
+ 
+ To get a rough speed between 30 and 44 MB/s of loading these files off
+ ext4 on nvme.
+ 
+ With lz4 initrd taking 67M, and gzip initrd taking 59M, the grub i/o
+ penalty is 0.18s whilst I gain over a second in faster decompression
+ time. Overall a win.
+ 
+ xz initrd is 36M meaning saving e.g. 0.8s of i/o time whilst gaining
+ 2.4s of decompression time, meaning overall worse than gzip.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1831736

Title:
  [MIR] lz4 by default

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1831736/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to