You are not logged in.
Pages: 1
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 0Relevant 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.599sAnyway, 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
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. ![]()
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
Yes, it is. My hostname is HAL9000 (reference to my beloved Stanley Kubric), nothing related to HAL labs. It is a DELL Inspiron laptop. ![]()
Offline
Ok, we have an advance here.
I have blacklisted nouveau creating the file:
/etc/modprobe.d/blacklist.conf
--------------------------------------------------
blacklist nouveauThis (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.257sNow 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
Pages: 1