Any comments about these 2 points: On Fri, Mar 18, 2011 at 1:40 PM, Gustavo Sverzut Barbieri <barbi...@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: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
