Il 06/11/2017 12:33, Marco Calistri ha scritto:
Il 06/11/2017 11:22, Anton Aylward ha scritto:
On 06/11/17 07:07 AM, Arjen de Korte wrote:
So now I would like to ask: why SuSEfirewall2_init.service, display-manager.service, NetworkManager.service, took so long time to be up and running at least on my system?
I don't know if there is a way to check this, but I highly suspect these services are waiting for disk-I/O. All caches are empty at boot time, so everything has to come from disk. This is where SSD drives with essentially zero seek times shine. Changing to SSD drives has been the single biggest performance improvement on my systems.
The first thing that Marco needs to understand is the dependency chain. That's why Carlos pointed to "critical-chain". Ff course that's not the full chain. The critical chain is a one-dimensional slice of the start-up order, which is actually a lot in parallel.
To see it all, you need to use the "plot" option. OH MY!
I've saved an html and a SVG output plot, I will review as soon as possible
The second thing is that yes, there is kernel time, but there is also time in userspace those apps spend initializing, chundling the results of reading those table and caches.
# systemd-analyze time Startup finished in 4.103s (kernel) + 4.227s (initrd) + 32.196s (userspace) = 40.526s
I don't remember now my result of the above command...I will run it again and compare with your.
Cheers,
-- Marco Calistri
Hello, At first attempt my result for systemd-analyze time has been around 40 s as your. I Googled a bit and encountered an interesting article wrote for Arch: https://wiki.archlinux.org/index.php/Improve_boot_performance_(Italiano) I verified that in my system the Staggered Spin-Up was enabled: Staggered spin-up Some hardware implements staggered spin-up, which causes the OS to probe ATA interfaces serially, which can spin up the drives one-by-one and reduce the peak power usage. This slows down the boot speed, and on most consumer hardware provides no benefits at all since the drives will already spin-up immediately when the power is turned on. To check if SSS is being used: dmesg | grep SSS Then I have disabled it by putting the kernel parameter: libahci.ignore_sss=1 into my /etc/default/grub. When I rebooted, I notice an overall boot time duration 7 seconds faster!: marco@linux-turion64:~> systemd-analyze time Startup finished in 3.479s (kernel) + 4.444s (initrd) + 26.041s (userspace) = 33.964s Of course I'm still very far to the "under 10 seconds boot time" but I'm very happy to be achieved this first result. Regards, -- Marco Calistri Linux version : openSUSE Tumbleweed 20171102 Kernel: 4.13.11-1.g0526da3-default - Cinnamon 3.6.0 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org