A Two-Second Boot Time With systemd

[curaga]

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

[liam]

I wish Lennart was a little more ambitious.

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.

[kees]

everything removed?

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.

[Teho]

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.

[russofris]

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

[balouba]

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.

[Teho]

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.

[Wyatt]

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.

[Kano]

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.

[russofris]

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