Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #888822 > unrolled thread

Bug#893845: initramfs-tools: Add LZ4 support

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#893845: initramfs-tools: Add LZ4 support Paul Menzel <pmenzel+bugs.debian.org@molgen.mpg.de> - 2018-03-23 08:30 +0100
    Bug#893845: initramfs-tools: Add LZ4 support Bastian Blank <bblank@thinkmo.de> - 2018-03-23 09:10 +0100
      Bug#893845: initramfs-tools: Add LZ4 support Paul Menzel <pmenzel+bugs.debian.org@molgen.mpg.de> - 2018-03-23 09:40 +0100

#888822 — Bug#893845: initramfs-tools: Add LZ4 support

Package: initramfs-tools
Version: 0.130
Severity: wishlist

Dear Debian folks,


It’d be great if you added LZ4 support to initramfs-tools.

There is a patch on Launchpad [1][2], which should apply easily to the 
Debian package.

An initramfs image file compressed with `gzip` has a size of 24 MB, 
while with an image compressed with `lz4 -9 -l` the size is 38 MB.

On a Dell XPS 13 9370 with an Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz 
and an NVMe SSD `populate_rootfs` takes 600 ms with the `gzip` 
compressed image, while only 190 ms with the `lz4` compressed image. 
(Only measured the LZ4 once.)

This can be easily measured by adding `initcall_debug` to the Linux 
kernel command line – for example by editing `/etc/default/grub.cfg` and 
running `sudo update-grub`. Then, after a reboot, look in the Linux 
message with `journalctl -k` or `dmesg` and look for `populate_rootfs`.

As for some users boot speed is quite important, shaving 400 ms off the 
boot time is quite nice.

Please tell me, if you need any help with that.


Kind regards,

Paul


[1]: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1488620
      "Add LZ4 support"
[2]: 
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1488620/comments/5

[toc] | [next] | [standalone]

#888826

On Fri, Mar 23, 2018 at 08:16:11AM +0100, Paul Menzel wrote:
> As for some users boot speed is quite important, shaving 400 ms off the boot
> time is quite nice.

And then they use BIOS which is aweful slow in disk access, so the time
is used instead to actually read the blocks from disk?

Bastian

-- 
Dammit Jim, I'm an actor, not a doctor.

[toc] | [prev] | [next] | [standalone]

#888831

Dear Bastian,


On 03/23/2018 09:07 AM, Bastian Blank wrote:
> On Fri, Mar 23, 2018 at 08:16:11AM +0100, Paul Menzel wrote:
>> As for some users boot speed is quite important, shaving 400 ms off the boot
>> time is quite nice.
> 
> And then they use BIOS which is aweful slow in disk access, so the time
> is used instead to actually read the blocks from disk?

Sure, the majority of the systems have that problem of slow firmware, 
currently it’s UEFI firmware and not the BIOS anymore, and only a few 
have alternatives like coreboot or U-Boot. I do not see how that is 
related though to the bug report.

But as you brought it up, my Lenovo X60 the coreboot firmware takes less 
than 500 ms, and on the ASRock E350M1 around one second with SeaBIOS as 
payload.

Additionally, millions of laptops run coreboot on Google Chromebooks and 
Chromeboxes. So yes, there are devices out there, where you can get boot 
times to the login screen in well below ten seconds, and it’d be great 
if developers and users would focus on this issue too, that means, 
monitor/benchmark/instrument these things, document it, and report bugs 
and feature requests about this.


Kind regards,

Paul

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web