You are not logged in.

#1 2019-05-28 14:25:50

jecogeo
Member
Registered: 2019-05-27
Posts: 29

[Solved] Improve boot time on SSD

I read a couple of topics here and followed the Improving performance/Boot process, however, it seems my bottleneck is not the kernel, but the userspace. I have a standard install of Arch, (base, base-devel, gnome, gnome-extra, GDM), with the system installed in a LITEON SSD 128GB (separate partitions for / and /boot and swap) and my /home being an HDD 1TB.

# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
# /dev/sdb2
UUID=xxx           /         	ext4      	rw,relatime	0 1

# /dev/sdb1 LABEL=ESP
UUID=xxx      	/efi      	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro	0 2

# /dev/sda1
UUID=xxx	/home     	ext4      	rw,relatime	0 2

# /dev/sdb3
UUID=xxx	none      	swap      	defaults  	0 0

Relevant lspci ouputs are as follows:

00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (Whiskey Lake)
            DeviceName: Onboard - Video
            Kernel driver in use: i915
	    Kernel modules: i915
02:00.0 3D controller: NVIDIA Corporation GP108M [GeForce MX150] (rev a1)
            Subsystem: Dell GP108M [GeForce MX150]
            Kernel driver in use: nouveau
            Kernel modules: nouveau
00:17.0 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller [RAID mode] (rev 30)
            Kernel driver in use: ahci
            Kernel modules: ahci
02:00.0 3D controller: NVIDIA Corporation GP108M [GeForce MX150] (rev a1)

And here is the boot times:

$ systemd-analyze                                                                                                                                
tartup finished in 12.671s (firmware) + 5.776s (loader) + 2.634s (kernel) + 2.957s (userspace) = 24.039s 
graphical.target reached after 2.596s in userspace

$ systemd-analyze blame                                                                                                                          
           1.011s systemd-logind.service
           512ms systemd-fsck@dev-disk-by\x2duuid-1ec7a464\x2d0bb7\x2d4e96\x2d8e4a\x2df9d5bb9001fb.service
           455ms lvm2-monitor.service
           405ms udisks2.service
           360ms tlp.service
           348ms dev-sdb2.device
           251ms home.mount
           223ms systemd-udevd.service
           187ms upower.service
           160ms systemd-journald.service
           128ms systemd-backlight@leds:dell::kbd_backlight.service
           119ms systemd-journal-flush.service
           116ms accounts-daemon.service
            98ms NetworkManager.service
            95ms polkit.service
            77ms user@1000.service
            52ms systemd-tmpfiles-clean.service
            47ms systemd-fsck@dev-disk-by\x2duuid-8613\x2dE978.service
            45ms systemd-udev-trigger.service
            45ms dev-disk-by\x2duuid-bc252205\x2ddf5b\x2d40e6\x2db0f4\x2dd0733bc98a55.swap
            28ms colord.service
            25ms efi.mount
            25ms gdm.service
            24ms systemd-tmpfiles-setup-dev.service
            22ms systemd-modules-load.service
            20ms systemd-tmpfiles-setup.service
            18ms systemd-update-utmp.service
            17ms systemd-backlight@backlight:intel_backlight.service
            16ms bluetooth.service
            12ms wpa_supplicant.service
            11ms user-runtime-dir@1000.service
            11ms sys-fs-fuse-connections.mount
             9ms systemd-user-sessions.service
             8ms kmod-static-nodes.service
             8ms systemd-sysctl.service
             6ms systemd-remount-fs.service
             6ms dev-mqueue.mount
             5ms systemd-random-seed.service
             4ms rtkit-daemon.service
             3ms dev-hugepages.mount
             3ms sys-kernel-debug.mount
             2ms sys-kernel-config.mount
             1ms tmp.mount

$ systemd-analyze critical-chain                                                                                                                                                                     
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @2.596s
└─multi-user.target @2.595s
  └─systemd-logind.service @1.583s +1.011s
    └─nss-user-lookup.target @2.599s

Anyway, the output from systemd-analyze is quite unrealistic. I've manually chronometered boot time since the vendor logo and it gave me around 50 seconds from the vendor logo until the login screen (more ~6 seconds after I input the password to have the system functional).

Here is a selection of what I think could be useful outputs from journal. I still don't fully know the boot process, so it's hard to me to figure out what is going on. What sounds strange in this journal, is the several lines of nouveau timeouts. Maybe it's something linked to my graphic cards/drivers? Or GDM it self? Ideas?

Last edited by jecogeo (2020-02-28 21:34:44)

Offline

#2 2019-05-28 14:41:33

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 20,715

Re: [Solved] Improve boot time on SSD

Is your hostname set properly?  The log looks like it is, but delays you described are often symptoms of that.

Also, remember that Arch is supported only on x86_64; Any implementation on HAL Laboratories hardware is going to be purely experimental. wink

Last edited by ewaller (2019-05-28 14:42:34)


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way

Offline

#3 2019-05-28 14:48:29

jecogeo
Member
Registered: 2019-05-27
Posts: 29

Re: [Solved] Improve boot time on SSD

Yes, it is. My hostname is HAL9000 (reference to my beloved Stanley Kubric), nothing related to HAL labs. It is a DELL Inspiron laptop. wink

Offline

#4 2019-06-03 04:30:40

jecogeo
Member
Registered: 2019-05-27
Posts: 29

Re: [Solved] Improve boot time on SSD

Ok, we have an advance here.

I have blacklisted nouveau creating the file:

/etc/modprobe.d/blacklist.conf
--------------------------------------------------
blacklist nouveau

This (thanks Hellsberg from #archlinux on freenode) improved the boot time a lot (apart from deactivated RAID on BIOS).


~$ systemd-analyze                                                                                                                                
Startup finished in 8.782s (firmware) + 1.365s (loader) + 2.440s (kernel) + 2.767s (userspace) = 15.357s 
graphical.target reached after 2.254s in userspace


~$ systemd-analyze blame                                                                                                                          
           712ms systemd-logind.service
           570ms lvm2-monitor.service
           506ms tlp.service
           436ms systemd-journal-flush.service
           425ms dev-sdb2.device
           410ms systemd-fsck@dev-disk-by\x2duuid-1ec7a464\x2d0bb7\x2d4e96\x2d8e4a\x2df9d5bb9001fb.service
           283ms udisks2.service
           220ms systemd-udevd.service
           185ms home.mount
           166ms upower.service
           163ms NetworkManager.service
           162ms systemd-journald.service
           158ms user@1000.service
           145ms accounts-daemon.service
           120ms polkit.service
            93ms systemd-fsck@dev-disk-by\x2duuid-8613\x2dE978.service
            53ms systemd-backlight@leds:dell::kbd_backlight.service
            46ms systemd-tmpfiles-clean.service
            40ms systemd-udev-trigger.service
            35ms systemd-tmpfiles-setup.service
            33ms systemd-backlight@backlight:intel_backlight.service
            31ms gdm.service
            29ms efi.mount
            26ms user-runtime-dir@1000.service
            26ms colord.service
            22ms systemd-tmpfiles-setup-dev.service
            20ms systemd-update-utmp.service
            19ms systemd-user-sessions.service
            19ms bluetooth.service
            18ms systemd-modules-load.service
            17ms dev-disk-by\x2duuid-bc252205\x2ddf5b\x2d40e6\x2db0f4\x2dd0733bc98a55.swap
            16ms wpa_supplicant.service
            12ms sys-fs-fuse-connections.mount
             8ms systemd-sysctl.service
             7ms rtkit-daemon.service
             6ms dev-mqueue.mount
             6ms systemd-remount-fs.service
             6ms sys-kernel-debug.mount
             4ms systemd-random-seed.service
             4ms kmod-static-nodes.service
             2ms sys-kernel-config.mount
             2ms tmp.mount
             1ms dev-hugepages.mount


~$ systemd-analyze critical-chain                                                                                                                 
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @2.254s
└─multi-user.target @2.254s
  └─systemd-logind.service @1.541s +712ms
    └─nss-user-lookup.target @2.257s

Now I have around 30 seconds of boot time, what is pretty decent. I'll keep trying to make it even faster.
The next door to knock is systemd.logind.service. Not the end of the history yet. If someone have any idea, please share.

Offline

Board footer

Powered by FluxBB