A $317 Core i7 CPU + SSD equals fast boot. News at eleven.
Announcement
Collapse
No announcement yet.
A Two-Second Boot Time With systemd
Collapse
X
-
I wish Lennart was a little more ambitious.
Originally posted by phoronix View PostPhoronix: 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
-
everything removed?
Originally posted by pingufunkybeat View PostIt'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.
Comment
-
Originally posted by kees View PostAnd 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.
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; 14 May 2012, 02:49 PM.
Comment
-
Originally posted by johnc View PostThere 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.
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
-
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
-
Originally posted by balouba View PostKDE 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 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
-
Originally posted by Kano View PostDon'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 may be mistaken about UEFI's both implementation, having read only a handful of pages of the spec.
F
Comment
Comment