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

  • Michael
    replied
    Originally posted by TheLexMachine View Post

    Because - as you yourself said in your review - it has some nuisances and drawbacks. For a personal use system, I want something a bit more polished and put-together, with the ability to install the stuff I want to install, without having to do a ton of manual config work via command line, hacks, or text file configs.
    It's getting fairly polished these days, even more so since switching to it myself they introduced their new installer / developer edition and other enhancements. More than likely Intel would better polish Clear Linux itself than the chances of someone else creating a downstream of it and trying to get it all polished into a better state.

    Leave a comment:


  • TheLexMachine
    replied
    Originally posted by Michael View Post

    Why not just use Clear Linux itself?
    Because - as you yourself said in your review - it has some nuisances and drawbacks. For a personal use system, I want something a bit more polished and put-together, with the ability to install the stuff I want to install, without having to do a ton of manual config work via command line, hacks, or text file configs.

    Leave a comment:


  • M@GOid
    replied
    Originally posted by hotaru View Post

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

    Leave a comment:


  • M@GOid
    replied
    Originally posted by V1tol View Post

    Actually you can boot into UEFI in this case - Windows 10 has a special button in Settings app On Linux Google says
    Code:
    systemctl reboot --firmware-setup
    can do that also.
    That is nice to see, will try it in the weekend.

    Leave a comment:


  • V10lator
    replied
    Originally posted by kokoko3k View Post
    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.

    Leave a comment:


  • polarathene
    replied
    Originally posted by caligula View Post
    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.

    Originally posted by hotaru View Post
    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.

    Leave a comment:


  • polarathene
    replied
    Originally posted by M@GOid View Post
    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.

    Leave a comment:


  • andyprough
    replied
    Originally posted by starshipeleven View Post
    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.

    Leave a comment:


  • hotaru
    replied
    Originally posted by M@GOid View Post
    @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.

    Leave a comment:


  • chilinux
    replied
    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.

    Leave a comment:

Working...
X