[systemd-devel] Improve boot-time of systemd

[Gustavo Sverzut Barbieri]

Any comments about these 2 points:

On Fri, Mar 18, 2011 at 1:40 PM, Gustavo Sverzut Barbieri
<barbieri at profusion.mobi> wrote:
>>> 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.


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