Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • starshipeleven
    replied
    Originally posted by hotaru View Post

    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.

    Leave a comment:


  • tildearrow
    replied
    Originally posted by SystemCrasher View Post
    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).

    Leave a comment:


  • hotaru
    replied
    Originally posted by [email protected] View Post

    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.

    Leave a comment:


  • caligula
    replied
    Originally posted by polarathene View Post
    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.
    Last edited by caligula; 09-12-2019, 03:59 PM.

    Leave a comment:


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

    Leave a comment:


  • SystemCrasher
    replied
    Originally posted by mlau View Post
    It seems there's still a lot to gain by throwing away old x86 baggage (UEFI, ACPI). 500ms just to get linux to load is a lot of time when the CPU runs at >2GHz.
    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).
    Last edited by SystemCrasher; 09-12-2019, 11:21 AM.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by polarathene View Post

    The command for rebooting into UEFI settings given earlier was because when using a feature like UltraFastBoot, Grub or rEFInd become unresponsive to input devices, the system needs to get past that and start booting the OS.
    Ok.

    In that case you can ask GRUB to boot a specific entry on next boot by
    sudo grub-editenv - set next_entry=X
    where X is the menu entry you want to boot next time.

    List available entries with
    Code:
    sudo  awk -F\' '$1=="menuentry " || $1=="submenu " {print i++ " : " $2}; /\tmenuentry / {print "\t" i-1">"j++ " : " $2};' /boot/grub2/grub.cfg
    or
    Code:
    sudo  awk -F\' '$1=="menuentry " || $1=="submenu " {print i++ " : " $2}; /\tmenuentry / {print "\t" i-1">"j++ " : " $2};' /boot/grub/grub.cfg
    or edit the last path to point to where your distro places grub.cfg.

    an example.

    Code:
    0 : openSUSE Tumbleweed
    1 : Advanced options for openSUSE Tumbleweed
            1>0 : openSUSE Tumbleweed, with Linux 5.2.11-1-default
            1>1 : openSUSE Tumbleweed, with Linux 5.2.11-1-default (recovery mode)
            1>2 : openSUSE Tumbleweed, with Linux 5.2.10-1-default
            1>3 : openSUSE Tumbleweed, with Linux 5.2.10-1-default (recovery mode)
    2 : Windows Boot Manager (on /dev/sdc2)
    On OpenSUSE there is grub2-once that is basically a Perl script wrapper for the above and is a bit more advanced because OpenSUSE has snapshots and stuff and you might need to do this to rollback.
    This is what I can also do with GRUB interface.
    Code:
    sudo  grub2-once --list
         0 openSUSE Tumbleweed
         1 Advanced options for openSUSE Tumbleweed>openSUSE Tumbleweed, with Linux 5.2.11-1-default
         2 Advanced options for openSUSE Tumbleweed>openSUSE Tumbleweed, with Linux 5.2.11-1-default (recovery mode)
         3 Advanced options for openSUSE Tumbleweed>openSUSE Tumbleweed, with Linux 5.2.10-1-default
         4 Advanced options for openSUSE Tumbleweed>openSUSE Tumbleweed, with Linux 5.2.10-1-default (recovery mode)
         5 Windows Boot Manager (on /dev/sdc2)
         6 Start bootloader from a read-only snapshot> openSUSE Tumbleweed  (5.2.11-1,2019-09-11T08:31,post,zypp(packagekitd))
         7 Start bootloader from a read-only snapshot> openSUSE Tumbleweed  (5.2.11-1,2019-09-11T08:29,post,yast snapper)
         8 Start bootloader from a read-only snapshot> openSUSE Tumbleweed  (5.2.11-1,2019-09-11T08:29,pre,yast snapper)
         9 Start bootloader from a read-only snapshot> openSUSE Tumbleweed  (5.2.11-1,2019-09-11T08:27,pre,zypp(packagekitd))
        10 Start bootloader from a read-only snapshot> openSUSE Tumbleweed  (5.2.11-1,2019-09-09T07:13,post,zypp(zypper))
        11 Start bootloader from a read-only snapshot> openSUSE Tumbleweed  (5.2.11-1,2019-09-09T07:10,pre,zypp(zypper))
        12 Start bootloader from a read-only snapshot>*openSUSE Tumbleweed  (5.2.11-1,2019-09-05T16:10,post,zypp(zypper))
        13 Start bootloader from a read-only snapshot>*openSUSE Tumbleweed  (5.2.10-1,2019-09-05T16:06,pre,zypp(zypper))

    This is useful for rebooting to UEFI settings if you added the menu entry as said above, and also for changing the kernel, or boot any other menu entry too, as you cannot do that anymore if you can't use the keyboard on boot.

    I don't know about a similar functioanlity in rEFInd, but quite frankly if you have rEFInd you are not going to have UltraFastBoot enabled.
    Last edited by starshipeleven; 09-12-2019, 11:10 AM.

    Leave a comment:


  • polarathene
    replied
    Originally posted by starshipeleven View Post
    If the above does not work
    The command for rebooting into UEFI settings given earlier was because when using a feature like UltraFastBoot, Grub or rEFInd become unresponsive to input devices, the system needs to get past that and start booting the OS.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by [email protected] View Post
    That is nice to see, will try it in the weekend.
    GRUB is also able to do that with the "grub commands", in UEFI systems there is a command to reboot to UEFI setup, "fwsetup".
    You can add them as GRUB menu options or by getting into GRUB commandline and writing the command directly
    https://wiki.archlinux.org/index.php/GRUB#GRUB_commands

    Also rEFInd boot loader/manager can do that (and offers it by default).

    If the above does not work (many want UEFI to not be like that, but it do), there is a more manual way with efibootmgr (that writes this in UEFI vars) from inside the booted system.

    It's usually

    sudo efibootmgr -n 0

    as the "0" boot option is commonly the UEFI setup menu or a boot menu where you can then select to go in UEFI setup, but check what options you actually have in your system.

    sudo efibootmgr

    See the following example for a HP laptop
    Code:
    BootCurrent: 000A
    Timeout: 0 seconds
    BootOrder: 000A,000B,000E,000F,0010,000D,000C,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,0011
    Boot0000  Startup Menu
    Boot0001  System Information
    Boot0002  Bios Setup
    Boot0003  3rd Party Option ROM Management
    Boot0004  System Diagnostics
    Boot0005  System Diagnostics
    Boot0006  System Diagnostics
    Boot0007  System Diagnostics
    Boot0008  Boot Menu
    Boot0009  HP Recovery
    Boot000A* opensuse-secureboot
    Boot000B* Windows Boot Manager
    Boot000C* Samsung SSD 850 EVO 1TB
    Boot000D* WDC WD5000LPCX-60VHAT0
    Boot000E* Samsung SSD 850 EVO 1TB

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by andyprough View Post
    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.
    Ok, ok, that's a special case, you can get away with less if your hardware is more powerful.

    Those times are from an embedded device running Debian. Kirkwood SoC. Not terribly powerful ARMv5 (armel Debian arch), and OS is on a flash drive that isn't particularly fast. Took 1 minute and something to fully boot the OS and the 2-3 services I needed it to do.
    And no it was not just sitting there waiting for ethernet connection.

    Switched to systemd on the same system when Debian did the switch, boom. 20 seconds of OS boot time, like a boss.

    Leave a comment:

Working...
X