On Fri, Mar 18, 2011 at 10:52 AM, Andrey Borzenkov <arvidj...@mail.ru> wrote: > On Fri, Mar 18, 2011 at 12:35 PM, fykc...@gmail.com <fykc...@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: 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
