1. 28
  1.  

  2. 8

    Fast booting Linux is cool but, for severs (not consumer grade machines), the BIOS/UEFI tend to be so long that the kernel boot time becomes negligible anyway.

    However, I understand that fastboot can be a great value for IoT devices.

      1. 2

        How long does UEFI spend? I’m just glad I don’t have to wait for the memory test in POST any more….

        1. 3

          I’ve already seen 10-30 sec UEFI runtime before even seeing the GRUB interface! With HPE, Dell and Supermicro (which seemed to be the less worse) servers.

          1. 2

            That’s crazy! What’s it doing in all that time?

            1. 2

              I suppose there are a lot of hardware checks (RAID controller, network cards, RAM, …). Since it’s enterprise-grade hardware, I guess those checks are desirable before booting the OS to avoid HW-related crash during production. But, I can be mistaken.

      2. 6

        I didn’t know about “In-kernel Deferred Memory Init”. It’s amazing how monoliths become Legos the more you know about them.

        1. 4

          Use loadable module when possible

          That seems counterintuitive to me – if you know the exact hardware you’re building your kernel, why not build all those drivers into a non-modular kernel? Doesn’t loading a module at runtime imply some non-zero amount of extra work (memory allocation, symbol lookup/linkage, etc.) that a non-modular build effectively gets out of the way at compile time?

          1. 1

            Additionally, I always believed that the hardware detection step can take huge amounts of time, with hardware being slow to respond, so I’m also surprised by this guideline…?

            1. 4

              Detection is mostly orthogonal to modularity. If you have static modules for PCIe/SATA/USB/etc., you still have to probe these buses at runtime :) And vice versa, there’s often modules loaded for devices statically described in FDTs.

              (I have seen PCIe devices described in ACPI (and FDT too?), but I don’t know if anyone actually turns enumeration off in favor of these descriptions)

          2. 2

            Seems obvious to me from the graph, the answer is to drop systemd, it is taking most of the time and providing basically no value. Try runit, perpd or something custom.

            1. 1

              They have only 2 second to start everything: HW, FW, Bootloader, Kernel, Systemd and Camera App. Systemd + Camera App is around 1.2 seconds. Even if you just drop systemd, without their optimization of kernel boot time it wouldn’t enough.

            2. 1

              I’m excited about this. I have an on-demand PXE cluster that could benefit from anything that takes a few seconds off of the boot time.