[systemd-devel] Improve boot-time of systemd

[Gustavo Sverzut Barbieri]

On Fri, Mar 18, 2011 at 10:52 AM, Andrey Borzenkov <arvidjaar at mail.ru> wrote:
> On Fri, Mar 18, 2011 at 12:35 PM, fykcee1 at gmail.com <fykcee1 at gmail.com> wrote:
>> Hi all,
>>
>> We did a series boot-time tests of systemd, and found some interesting things:
>> (Note the tests were performed on a laptop with a 4-core mips cpu, AMD
>> RS780 chipset, 2GB Memory, rotate harddisk with ext4 filesystem,
>> debian squeeze, Linux 2.6.36 with fanotify enabled, systemd-v20, only
>> boot to console.)
>>
>> 1. What can readahead affect boot-time?
>> Sadly observed negative affect -- boot-time increases at least 1s.
>
> From subjective feelings (no real measurements) I confirm it.

I noticed it as well, even with my Macbook Pro i7 with 8Gb RAM and
128SSD using btrfs.



>> With bootchart, I find more I/O at boot compared with no readahead,
>> see attachment noreadahead-vs-readahead.png.
>> Thoughts: Maybe we need only monitor files with read access, not all
>> opend files? P.S. inotify seems enough for the job (with one more step
>> to open each file).
>>
>> 2. udev-settle.service serializes the boot process, see attachment
>> udev-settle.png.
>
> I have feeling that increased parallelism during boot (like starting
> fsck/mount as soon as device becomes available) actually has negative
> effect on consumer grade devices. My HDD in notebook simply is not
> prepared for it ...

ACK. Maybe we should add some intelligence to systemd's automatic
unit-mount creation and serialize partition mounts of the same device?
For traditional systems it's easy, just make all /dev/sda* depend on
each other, but world is bit harder and multiple-device FS like btrfs
or even DM will screw with that. Ideas? Maybe we could do it just
based on /etc/fstab, sorting dependencies based on /dev/sda* and
respective mountpoints.


>> I tried to create a hotplug.target(which is activated after
>> default.target), and made udev-settle reside at it, this rendered a
>> unbootable system. systemd depends on udev at early time.
>> Thoughts: devtmpfs is mounted, so all cold-plug jobs can be done
>> without udev involved.
>> IMHO, fast boot doesn't mean get all services ready in a short time,
>> but means popup an UI as soon as possible. Windows seems do hotplug
>> jobs after user log in.
>>
>
> Mandriva uses so called "speedboot" with sysvint - where GUI is
> started as soon as possible. It is handcrafted so that only several
> device classes are coldplugged and then DM is launched effectively
> from rc.sysinit already.
>
> Users did mention that boot under systemd actually feels slower then
> using sysvinit.

Well, I never tried other distro other than Gentoo on this Macbook and
here it's kinda fast at 7s to be 100% ready with E17 (I have an
autostart .desktop that writes to /dev/kmsg to measure it), "Startup
finished in 2s 360ms 651us (kernel) + 1s 753ms 783us (userspace) = 4s
114ms 434us."

But it could be improved yes. As you all said, maybe we should handle
udev hotplug in a more throttled way by postponing non-critical
devices and having everything else to be hotplug aware? AFAIK Xorg
will handle nicely new input devices. ConnMan/NetworkManager will
handle nicely network devices. Same for bluez. We could even just
activate these services based on the presence of the devices, at least
E17 will handle nicely daemons appearing later by means of DBus
NameOwnerChanged.

Ideas:
  1. should we change ConnMan and NetworkManager to work as BlueZ an
be able to be activated/shutdown by udev hotplug actions (but
cooperative with systemd, bluetoothd is not AFAIR);
  2. should we do (or have a way to) force a manual ordering to help
Xorg/DM/WM by avoiding spawn of concurrent services? We know these
have the higher priority, but it's a higher priority only during
startup, later on they should all have the same priority... otherwise
we could just do it by means of systemd's service settings.


A hackish(?) solution would be to have a BootPriority=(True|False),
set to False by default and True for services we care most. Lower
priority services would be set to "background" priority in IO, CPU and
others, then being reset to actual values when systemd is notified.
Problem is we need to notify Systemd of that, as it's not a matter of
just starting "gdm", but actually gdm being in a "usable" state
(defined by gdm itself) or desktop being ready if users use autologin
(like I do). This could also be stated as "system is idle for X
seconds", which would be monitored by systemd itself and then no
manual notification is required.

As a last note, what piss me off is the fact that some things affect
boot time but they should not, and it's not systemd's fault. For
instance with both nvidia and intel on another PC I have around 1s
slowdown when I'm using external monitors! Damn, 14% of my boot time
because of that?

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri at gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202