How Intel's Clear Linux Team Cut The Kernel Boot Time From 3 Seconds To 300 ms

[caligula]

That loader part only shows if you include/use something in the initrd I think related to using systemd, and only for UEFI iirc.

Not really a problem.

My 2016 system has settings to speed up boot, FastBoot and UltraFastBoot. The latter will reduce the initialization time by firmware quite a bit iirc, but you'll not be able to have multi-boot setup without disabling it afaik, keyboard/mouse is unresponsive until the OS begins loading(or you reboot directly into BIOS/UEFI).

It's nice to have, but for me, the ultra fast boot is hardly any faster. Probably a bad UEFI BIOS on this board. I think the machine restarts about 3 times to "train" the DDR4. I can hear the fans spinning up 3 times. It goes a bit faster if I used the default memory settings, but in that case the DDR4-3200 memory would operate in DDR4-2666 mode. I can set the number of DDR4 training rounds from the BIOS. 3 seems to be the minimum, otherwise it won't boot.

Anyway the problem with the ultra fast boot mode is that if a kernel update won't boot, I'm stuck. Happened few times. I can't switch to some other boot entry since the keyboard won't work.

[hotaru]

That is a extreme case. None of my personal systems takes 15 seconds until grub show up. I'm not saying you haven't a system like that, but not all of them are as bad as this.

no, the Dell R420 I have that takes a full minute to get to the bootloader is an extreme case. about 15 seconds is the fastest I've seen for UEFI.

[tildearrow]

Hell yes. Also get rid of weird instruction set, overcomplicated overgrown CPU cores full of funny legacy like 16-bit mode, simplify design, add reasonable firmware ... and it maybe would look like ... er, ARM or RISC-V with something like u-boot (maybe only SPL part of it, if speed is all we care of - dumb as hell, not configurable, but FAST and does what it supposed to - without exposing gazillion of firmware bugs that nobody would ever fix anyway to Linux, like it usually happens on x86).

The problem is that by doing this they'll be dropping compatibility with e.g. BIOS. Yes, BIOS still requires 16-bit mode at the beginning and I'm pretty sure even UEFI does too (but initializes a 64-bit environment fairly quickly).

[starshipeleven]

no, the Dell R420 I have that takes a full minute to get to the bootloader is an extreme case. about 15 seconds is the fastest I've seen for UEFI.

That's a rack server. A full minute for UEFI in a server is common.

[starshipeleven]

The problem is that by doing this they'll be dropping compatibility with e.g. BIOS. Yes, BIOS still requires 16-bit mode at the beginning and I'm pretty sure even UEFI does too (but initializes a 64-bit environment fairly quickly).

I hope this is why they are dropping CSM ("legacy boot" or "BIOS boot" mode in UEFI) in a few years. So once the system simply can't boot BIOS OS anymore they can drop some of that old crap modes in the hardware.

[tildearrow]

That's a rack server. A full minute for UEFI in a server is common.

Is there any reason why does it take so long?

Too many disks to spin up maybe?

[hotaru]

Is there any reason why does it take so long?

Too many disks to spin up maybe?

nope, just 1 disk. apparently a full minute is common for servers. the server right below it (a Super Micro with twice as many CPUs and a lot more RAM) only takes 20 seconds, though, so there doesn't seem to be any reason for it to take so long other than Dell's UEFI firmware being shit.

[polarathene]

Anyway the problem with the ultra fast boot mode is that if a kernel update won't boot, I'm stuck. Happened few times. I can't switch to some other boot entry since the keyboard won't work.

Mine will disable the feature if it boots unsuccessfully 3 times iirc. Don't have to pop out the CMOS battery, personally easier to just detach the OS disk(s) by unplugging the SATA cables. I think it might prevent USB stick(or other storage) from being bootable option though, if not then having that as a higher priority when plugged in could work for recovery.

Really though, it's barely an important time savings as I rarely reboot(Once every few months usually), so I just don't see much point in it myself.

Can someone provides a list of modules that should be run in parallel to speed up boot? amdgpu?
driver_async_probe=[list]

It'd be nice to know how to query that in CLI. I see the description for using module.async_probe as an alternative way to load, but none of the modules I have loaded appear to have this as a parameter.

All the ones in the kernel that support async afaik are listed here:

https://github.com/torvalds/linux/search?q=PROBE_PREFER_ASYNCHRONOUS&unscoped_q=PROBE_PREFER_ASYNCHRONOUS

Based on probe_type enum docs: https://01.org/linuxgraphics/gfx-doc...l#c.probe_type

I have tried scanning (I guess only loaded modules?) for the param like this:
grep sync /sys/module/*/parameters/*

But only got "scan:async" as a result for scsi_mod.

[skeevy420]

Is there any reason why does it take so long?

Too many disks to spin up maybe?

I have a Dell T5500 Workstation and it takes around 10 seconds before the GPU outputs anything and another 20 seconds from there before Grub loads up.

Simply put: Enterprise grade Dell equipment is slow to boot due to having assloads of POSTs.

I'm specifically saying workstation because there's also a Dell T5500 laptop and it's a piece of crap.

[skeevy420]

nope, just 1 disk. apparently a full minute is common for servers. the server right below it (a Super Micro with twice as many CPUs and a lot more RAM) only takes 20 seconds, though, so there doesn't seem to be any reason for it to take so long other than Dell's UEFI firmware being shit.

Their BIOS is shit too

See above