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

[Michael]

I'd love to see a Clear Linux-based distro made specifically for Intel-based desktop computers like the NUC/Brix and the mid-range/low-end Intel laptops and ultrabooks that were sold over the past several years.

Why not just use Clear Linux itself?

[caligula]

Actually, most UEFI/BIOS have a option for quick boot. In fact, a Gigabyte mobo I have has a option that boots so fast, you loose the ability to enter again on the UEFI interface, until you erase the CMOS...

Try laptops instead. There's nothing you can do to speed them up. Those gamer desktop mobos can boot fast, but most enterprise laptops just won't do it.

[caligula]

Well, optimizing the boot time is nice, but I hope they could really focus on firmware instead of kernel/init:
Startup finished in 16.115s (firmware) + 339ms (loader) + 4.335s (kernel) + 2.296s (userspace) = 23.086s

I could probably shave off few seconds from kernel/userspace and disable the boot loader, but I couldn't find any way to optimize the UEFI firmware beyond 16 seconds.

[V1tol]

@R41N3R
@starshipeleven

Actually, most UEFI/BIOS have a option for quick boot. In fact, a Gigabyte mobo I have has a option that boots so fast, you loose the ability to enter again on the UEFI interface, until you erase the CMOS...

Actually you can boot into UEFI in this case - Windows 10 has a special button in Settings app On Linux Google says

systemctl reboot --firmware-setup

can do that also.

[chilinux]

It would be nice to see these types of changes applied to a common KVM/QEMU guest kernel configuration such as the virtio drivers.

There seems to periodically be edge cases were hot-migrations between hypervisors just does not work or is not an option. In those cases, the ability to shave 2 more seconds off the VM boot after a cold migration could have some benefits.

[hotaru]

@R41N3R
@starshipeleven

Actually, most UEFI/BIOS have a option for quick boot. In fact, a Gigabyte mobo I have has a option that boots so fast, you loose the ability to enter again on the UEFI interface, until you erase the CMOS...

while you can disable the ~3 second timeout for entering setup, those 3 seconds are insignificant compared to the 15 or more seconds the firmware takes regardless of the quick boot setting.

[andyprough]

More like "linux teams never needed to show off like this".

Kernel boot times of 3 seconds are more or less irrelevant when BIOS/UEFI part takes up to 10 seconds, or the onboard flash (embedded system) takes 5 seconds to read on boot, or the SoC init phase takes nearly 20 seconds (modern Qualcomm-Atheros SoCs for routers for example), and also the rest of the OS boot takes again 10 seconds with systemd or some minutes with SysV-like crap.

My sysvinit antiX system boots in a lot less than minutes. Not sure why it would take so long unless you purposely or incompetently set it up that way.

[polarathene]

you loose the ability to enter again on the UEFI interface, until you erase the CMOS...

Not true, and not just Gigabyte, my ASRock has the same additional level of FastBoot that does this where keyboard input has no effect until after loading the OS. You can reboot into UEFI via command line, and I think in the past year KDE added a UI option for it as one of the power options. You don't have to lose settings by popping out the CMOS battery.

[polarathene]

I could probably shave off few seconds from kernel/userspace and disable the boot loader, but I couldn't find any way to optimize the UEFI firmware beyond 16 seconds.

The firmware time isn't always accurate, but perhaps is for you. On my 2016 Skylake build, it seems to sometimes report the time since last reboot(up until a certain overflow period I think, then resets to count again), firmware bug I guess. It's been a while since I messed with boot times, can't recall where grub/systemd-boot delays contribute, was it firmware?(technically it's not, but it's prior to loading kernel/userspace as an OS isn't selected yet) If so that can be lowered if you have that presenting choices with a countdown.

Found an example from notes:

Startup finished in 35min 59.223s (firmware) + 3.864s (loader) + 1.075s (kernel) + 2.386s (userspace) = 36min 6.549s

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

while you can disable the ~3 second timeout for entering setup, those 3 seconds are insignificant compared to the 15 or more seconds the firmware takes regardless of the quick boot setting.

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).

I believe I had sub 1 second for kernel/userspace, and about 5 seconds for firmware. It's not an expensive motherboard, ASRock with H170 chipset for a i5-6500 Skylake, Crucial MX300 SSD. From there you've reached the DM and with that setup for autologin to the DE(KDE Plasma in my case), total time until usable desktop from cold boot was about 12 seconds I think?

I don't think there is anything special about my firmware, the motherboard did have an issue with some hardware clock resetting upon resume from suspend(affected my para-virtualized VM), I e-mailed ASRock support and they sent me a new firmware to flash that fixed that.

So uhh.. I guess my system boots in less time than your firmware takes? How old is your system? Could be that you have an outdated perspective of what more modern hardware is capable of, either that or your vendor writes poor firmware?(could be that your system has more work to initialize, I know that server grade hardware for enterprises can have ridiculously slow boot times)

I can't recall what the boot time for my firmware is like without enabling one of the FastBoot settings, I haven't bothered timing for a couple years now, maybe 20 seconds tops.

I have these results from my old notes when I did play around with it:

Startup finished in 647ms (kernel) + 461ms (userspace) = 1.109s

No other times were shown prior, perhaps due to the way the kernel was built or UltraFastBoot might have prevented that information being available somehow, not sure, my notes don't state why.

Startup finished in 53min 47.652s (firmware) + 3.300s (loader) + 307ms (kernel) + 839ms (initrd) + 790ms (userspace) = 53min 52.890s

That one is lying about the firmware time(bug). 52.89 - 47.652 - 3.3 = 1.938

Startup finished in 9.442s (firmware) + 938ms (loader) + 308ms (kernel) + 835ms (initrd) + 729ms (userspace) = 12.254s

That's probably accurate firmware time and without any FastBoot. Add another 5-7 seconds for booting from there into the DE that systemd-analyze doesn't account for. I do know I got the total time from boot to usable DE(KDE Plasma) down to 12 seconds(timed by stopwatch and video), so firmware time was knocked down a fair bit <5seconds.

Other variances were from messing around with different boot params, disabling services at boot that weren't necessary, trying different compression, etc.

[V10lator]

boot with mem=xxxxm (but how to add the memory back?)

It seems you need to probe it (CONFIG_ARCH_MEMORY_PROBE - echo [Physical Adress] > /sys/devices/system/memory/probe) and then either have your kernel configured to bring it online automatically (CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE) or bring them online by hand (echo online > /sys/devices/system/memory/memoryXXX/state). Repeat that for all needed adresses untill you have you whole RAM available.