Same here, I disabled IPv6 as well, went from wicked/DHCP over NetworkManager (first DHCP, then static IPv4 only) finally to systemd-networkd (minimal IPv4) only. Startup times between those services can be orders of magnitude (1s vs ca 200ms vs 25ms). For me, systemd-netwkorkd is the clear winner here.
Similarly with postfix: I tested it, then exim and found that exim had quicker startups. After a few years without emails, I decided to disable/mask/uninstall exim. Similar: ntpd→chronyd, also SDDM→XDM→KDM.
I blame systemd for rekindling my interest in the boot process. Having wrestled classical init scripts for over 20 years, I grew accustomed to the sad fact that every distro I have to work with professionally and at home, the startup scripts were always different, each distro had its quirks, bugs and packages for them. Systemd changed that: if a bug is found, all systemd-based distros benefit from the bugfix. And I benefit from learning about all that, meanwhile improving boot times from almost 20s down to about 3s (ok, the purchase of a faster SSD happened somewhere between those times as well).
After 6 years of minimizing startup times as a hobby using mostly systemd/udev/dracut, I have rediscovered another component worthy of close scrutiny:** the kernel itself. **
See, much in openSUSE is derived from the server-centric SuSE-SLES main line. Despite also having SLED as a desktop solution, both the SLES and SLED kernels seem to include everything a Linux server could possibly need: support for NUMA, LVM, btrfs, XFS, hugepages for massive DB (hello, SAP/HANA) and for virtualization setups, quotas and similar resource-management instrumentation. On the other hand, openSUSE being used on mobile hardware regularly, Wifi+Bluetooth+IPv6 are mandatory.
I invested a rainy weekend this summer to customize a kernel exactly for my needs: It was easy to dispose of all the components listed in the previous paragraph. Now when I restart my system, boot times are regularly under one second from Grub2 to KDE+networking. Cold boots are about 1.1 seconds. I’ve been using one primary ext4 partition spanning a whole MBR-partitioned SSD; no EFI boot, no swap, no initial ramdisks.
Not having all that functionality lets the kernel just fly through its initialization, then mount the boot device and invoke systemd. On the other hand, the kernel must now handle whatever initrd-based dracut and systemd previously had managed, in my case patch the microcode (CONFIG_EXTRA_FIRMWARE=“intel-ucode/06-3c-03” in my case, having a Haswell core-i5 CPU) and provide the filesystem driver for the boot device (CONFIG_EXT4_FS=y).
A few days ago, I compiled the 5.9.3 kernel and the newest Nvidia blobs (455.38) in one go, and for the first time it went flawlessly. It’s gratifying for me to still learn more things:
- Backup frequently so messing up is less painful.
- Optimizing the kernel for size or for performance only seems to result in different binary sizes. Personally, I didn’t notice any
differences in boot times or runtime performance of my usual workloads, including compiling a new kernel (which takes about 4 minutes).
- Despite the ongoing controversy between the kernel developers and Nvidia over EXPORT_SYMBOL_GPL, the newest 455.38 driver works perfectly with 5.9-mainline kernels so far — IFF
you don’t need CUDA (an obscure command-line option in NVidia’s install script called –no-unified-memory does the trick).
- It’s invaluable to consistently log results, document changes, measure times and resources, compare findings, and to automate as much of the process as reasonable; but without creating too much extra load to the system under test.
- Learning and exploiting quirks is fun, but riddle me this: having udev_log set to “debug” in /etc/udev/udev.conf produces almost 4000 lines of dmesg/journalctl messages during each boot — but it lets my system boot about 150ms faster than udev_log=“err” (which leads only to about 700 lines of boot messages total!). Why?
All that joyous tinkering because 6 years ago I was wondering »why does my new rig boot so slowly«?