Announcement

Collapse
No announcement yet.

A Two-Second Boot Time With systemd

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

  • #16
    Originally posted by pingufunkybeat View Post
    It's not a near-instantaneous boot, it's a near-instantaneous init.

    Boot goes like this:

    BIOS
    GRUB/lilo
    Kernel
    init <------ this is the part that was cut down from 7 seconds to 2 seconds
    X initialisation
    KDE/GNOME
    To make this more generic:

    Hardware/firmware init
    Bootloader
    Kernel
    service init
    Display server
    Window Manager.

    For appliances, we can actually combine the first three (think linux-bios) and do away with the WM in kiosk style implementations.

    For general purpose computing, we can do away with the majority of boot-from-off situations by improving support for sleep/hibernate. Aside from kernel updates, the only reasons I ever boot my systems is due to shortcomings in my OS's sleep/hibernate implementations.

    Look at the iPad as an example. Booting-from-off is a 30-60 second process, but since it has a proper sleep implementation, booting is an extremely rare occurrence.

    F

    Comment


    • #17
      Originally posted by pingufunkybeat View Post
      It's not a near-instantaneous boot, it's a near-instantaneous init.
      http://git.fenrus.org/tmp/bootchart-20120512-1036.svg

      XFCE desktop seems to be completely loaded in less than two seconds. It takes around 500ms for the kernel to load and another 500ms till the X.org can start then bit less than a second till the complete desktop (PulseAudio, Thunar, power management, XFCE panel...) is loaded. So yeah to me it seems that the entire boot proccess from the start of the kernel initialization to the usable desktop takes less than two seconds. Modern BIOS takes around one second to load so around three seconds total?

      Comment


      • #18
        Adding to my first post, I'd also like to add that the time your computer takes to boot depends strongly of your Hardware. In the case of systemd, I can assure using a HDD vs SSD is an important factor...

        Another important think that (might) wasn't mentioned in the systemd article is the fact a custom-optimized kernel might load significantly faster than the generic distro kernel (most of us) use, (OC, if you know the options to choose in your kernel .config)...

        Cheers

        Comment


        • #19
          There are a lot of people who still don't use suspend-to-ram, suprisingly.

          I boot maybe once every 10-30 days for a variety of reasons, and the boot time is short enough now that it never concerns me.

          Comment


          • #20
            Originally posted by evolution View Post
            Adding to my first post, I'd also like to add that the time your computer takes to boot depends strongly of your Hardware. In the case of systemd, I can assure using a HDD vs SSD is an important factor...

            Another important think that (might) wasn't mentioned in the systemd article is the fact a custom-optimized kernel might load significantly faster than the generic distro kernel (most of us) use, (OC, if you know the options to choose in your kernel .config)...

            Cheers
            The Wiki article mentions it.
            10. If you work on an appliance, make sure to build all drivers you need into the kernel, since module loading is slow. If you build a distribution at least built all the stuff 90% of all people need into your kernel, i.e. at least USB, AHCI and HDA!

            Comment


            • #21
              A $317 Core i7 CPU + SSD equals fast boot. News at eleven.

              Comment


              • #22
                I wish Lennart was a little more ambitious.

                Originally posted by phoronix View Post
                Phoronix: A Two-Second Boot Time With systemd

                Lennart Poettering has written a guide for optimizing systemd to the extent that a two-second boot-time or less for this popular free software project...

                http://www.phoronix.com/vr.php?view=MTEwMjc


                Close to when systemd first appeared I asked him about letting systemd BE the DM. Ive since forgotten his response but its clear there are great benefits to be had from making systemd a hard dependency for at least the two major DE. What I'd like to see is lightdm/gdm/kdm go away and let systemd handle all the services directly (some, like the login, would be special cases but the rest would simply be new cgs). Each desktop would bundle the needed services under a unit and systemd would start/stop/restart as requested.
                Some of these tasks are sort of handled currently via the special units (graphical, display-manager) but those are usually just wrappers. It all certainly works fine now but these seem like good candidates for direct management via a C unit that is based on a new fdo spec which the desktops would then hook into for their specific needs.
                As for e4rat, thats something I yet to mange to compile for Fedora. It uses, IIRC, the hellish cmake and has boost dependcies which seem unsatisfiable (despite using the cmake env variables or altering the cmake file itself). God, I hate cmake.

                Comment


                • #23
                  everything removed?

                  Originally posted by pingufunkybeat View Post
                  It's not a near-instantaneous boot, it's a near-instantaneous init.

                  Boot goes like this:

                  BIOS
                  GRUB/lilo
                  Kernel
                  init <------ this is the part that was cut down from 7 seconds to 2 seconds
                  X initialisation
                  KDE/GNOME

                  The whole boot process is still much longer than 10 seconds.

                  It's still impressive work, but some of the comments here are misleading. This is only a part of the boot process.
                  It's too bad everything useful got removed from init to make that happen. He should consider just using upstart instead. In recent timings I did, Chrome OS takes under a second to get from the kernel to X being started. And X was 800ms of that second, so if it's just the bit between Kernel and X that's getting measured, it's 10 times faster.

                  Comment


                  • #24
                    Originally posted by kees View Post
                    And X was 800ms of that second, so if it's just the bit between Kernel and X that's getting measured, it's 10 times faster.
                    No it's not... did you actually check the bootchart in the article? It takes 950ms from kernel initialization till X.org is being started. Not only that but also no actually important features for desktop user were removed...

                    Timeline:
                    0ms - kernel intialization starts.
                    550ms - systemd is started.
                    950ms - X.org is started.
                    1450ms - Xfce Panel, Thunar, Xfdesktop, xfwm are being started.
                    1900ms - XFCE desktop is loaded.

                    I would be interested if you could show me your bootchart from Chromium OS. I mean the wildest claims from Google give estimates like 5s till login screen. We are talking here about 1900ms till completely functional desktop.
                    Last edited by Teho; 05-14-2012, 02:49 PM.

                    Comment


                    • #25
                      Originally posted by johnc View Post
                      There are a lot of people who still don't use suspend-to-ram, suprisingly.

                      I boot maybe once every 10-30 days for a variety of reasons, and the boot time is short enough now that it never concerns me.
                      You are one of those fortunate enough to own a general purpose computer with a functional and reliable suspend-to-ram. My iMac and iPad do this reliably as well. The following PCs do not.

                      Gigabyte X38 based PC with 8800GT and Ubuntu - Occasionally does not wake, sometimes, does not display video on wake
                      Asus P7P55D based PC with 5750 and Win7 - Occasionally does not wake, sometimes, does not display video on wake
                      Lenovo T60 and T61 with XP - Works great for just-short-of a week, then stops sleeping altogether
                      Lenovo T400 with Windows 7 - Sleeps great until it goes to sleep with a VPN connected. Upon wake, VPN is borked, re-starting the VPN leads to blue screen. This happens with Cisco, windows, and Arraynet clients. I suspect VPNC will do the same, but have not tried it yet.

                      I'm sure that the faults lays with a variety of issues. Crappy hardware, crappy BIOS implementations, crappy OS implementations, crappy drivers. I am certain that a working sleep implementation would reduce the number cold-boots by several orders of magnitude.

                      F

                      Comment


                      • #26
                        I'm getting similar boot time between systemd and rc init (well, ArchLinux's one - its not SystemV either but its scripts).
                        KDE also takes most of the boot time (like, 3 or 4s on my system) and the disk is encrypted by LUKS in both cases.


                        I'm not currently seeing so much advantage with systemd mainly because it has this weirdo log mechanism, so even if it would be slightly faster on slower machines, i'd still feel bad about it.

                        In fact, what I like in ArchLinux in general, and this include their init, is that it's always simple and there's little binary/hard to figure out stuff. it's mostly all text. Yet it's light and fast. The way things should be IMO.

                        Instead of "lets put all in one process that does all the things!" i'd rather speed up script execution, caching, etc (and in clean ways, not in ramfs ways.. :P).

                        That's like upstart. What a f* mess to deal with as a user.

                        Comment


                        • #27
                          Originally posted by balouba View Post
                          KDE also takes most of the boot time (like, 3 or 4s on my system) and the disk is encrypted by LUKS in both cases.
                          Well the nice thing is that we can fix that with systemd in the future too. It's possible to use systemd as replacement for kdeinit and such and start all KDE services in parallel that leads to huge performance boosts. It has been done with Tizen already.

                          I personally like Arch partly because it considers systemd as a first class citizen. All new packages are compiled with systemd unit files and support enabled and they are even planning to move it to core in near future. It will probably replace the current init system but that could still take some time.

                          Comment


                          • #28
                            Oh, sounds like systemd is finally catching up to OpenRC. Took 'em a while; guess there are disadvantages to rewriting everything in really ugly C.

                            Comment


                            • #29
                              Don't forget that you can rid of the initial bootloader step when you use linux with efi stub. You dont need corebios for that just uefi.

                              Comment


                              • #30
                                Originally posted by Kano View Post
                                Don't forget that you can rid of the initial bootloader step when you use linux with efi stub. You dont need corebios for that just uefi.
                                I was under the impression that this simply moved the boot loader into the logic board's firmware. This is nice and all, but all that this really accomplishes (in the context of boot time) is the reduction of one pile-of-time and an increase in some-other-pile-of-time. In other words, there is no real net-gain, unless the UEFI boot loader implementation is significantly faster than grub.

                                I may be mistaken about UEFI's both implementation, having read only a handful of pages of the spec.

                                F

                                Comment

                                Working...
                                X