Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 41

Thread: A Two-Second Boot Time With systemd

  1. #21
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,130

    Default

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

  2. #22
    Join Date
    Jan 2009
    Posts
    1,419

    Default I wish Lennart was a little more ambitious.

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

  3. #23
    Join Date
    May 2012
    Posts
    1

    Default everything removed?

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

  4. #24
    Join Date
    Jul 2010
    Posts
    593

    Default

    Quote 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 at 02:49 PM.

  5. #25
    Join Date
    Jan 2009
    Posts
    464

    Default

    Quote 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

  6. #26
    Join Date
    Sep 2011
    Posts
    64

    Default

    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.

  7. #27
    Join Date
    Jul 2010
    Posts
    593

    Default

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

  8. #28
    Join Date
    Jan 2009
    Location
    Columbus, OH, USA
    Posts
    323

    Default

    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.

  9. #29
    Join Date
    Aug 2007
    Posts
    6,634

    Default

    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.

  10. #30
    Join Date
    Jan 2009
    Posts
    464

    Default

    Quote 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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •