Hi Tobias,
Thanks for looking into that.
adding opensuse-arm mailinglist, that's where further discussion should take place.
Comments below.
On 25/01/2019 20:54, admins wrote:
On 25.01.19 19:59, Bruno Friedmann wrote:
On jeudi, 24 janvier 2019 11.53:34 h CET Axel
Braun wrote:
Gesendet:
Donnerstag, 24. Januar 2019 um 08:53 Uhr
Von: "Matthias Brugger" <mbrugger(a)suse.com>
An: "Basil Chupin" <blchupin(a)iinet.net.au>au>, opensuse-project
<opensuse-project(a)opensuse.org> Cc: "nicolas saenz julienne"
<nicolassaenzj(a)gmail.com>
Betreff: Re: [opensuse-project] No info. re Leap 15.1 in Wikipedia
I think we read about people complaining on the performance of openSUSE
this week already. I haven't done any measurements but heard that on
Raspberry Pi 3, Debian is significantly faster in booting then openSUSE.
Raspi are
heavily depending on the kind of 'hard disk' you are using,
whether it is a SD card (connected via USB2) or an internal SSD Here is the
result of a Raspi using a Leap 15 LXQT image:
/home/test # systemd-analyze blame
1min 30.071s display-manager.service
1min 18.481s backup-rpmdb.service
14.815s ca-certificates.service
13.788s postfix.service
12.885s btrfsmaintenance-refresh.service
11.001s apparmor.service
10.121s logrotate.service
9.277s backup-sysconfig.service
7.925s ModemManager.service
7.755s lvm2-monitor.service
5.889s NetworkManager.service
5.086s postgresql.service
4.790s initrd-switch-root.service
3.074s systemd-journal-flush.service
2.868s nscd.service
2.721s kbdsettings.service
2.672s sshd.service
2.316s ntpd.service
2.191s avahi-daemon.service
2.153s systemd-udevd.service
1.967s polkit.service
1.959s user(a)1000.service
1.299s systemd-tmpfiles-setup-dev.service
1.171s systemd-remount-fs.service
1.095s sys-kernel-debug.mount
943ms systemd-logind.service
920ms upower.service
803ms wpa_supplicant.service
789ms dev-mqueue.mount
736ms dev-hugepages.mount
715ms boot-efi.mount
598ms udisks2.service
493ms systemd-journald.service
482ms initrd-parse-etc.service
440ms systemd-udev-trigger.service
436ms systemd-modules-load.service
435ms auditd.service
403ms dracut-cmdline.service
348ms systemd-random-seed.service
251ms initrd-cleanup.service
250ms systemd-tmpfiles-setup.service
247ms systemd-sysctl.service
210ms systemd-update-utmp-runlevel.service
207ms
dev-disk-by\x2duuid-d90960ec\x2df373\x2d472d\x2d8b3f\x2d27a48d232d7a.swap
193ms systemd-fsck-root.service
184ms plymouth-switch-root.service
170ms sysroot.mount
166ms sys-fs-fuse-connections.mount
159ms systemd-user-sessions.service
151ms kmod-static-nodes.service
112ms systemd-rfkill.service
98ms plymouth-quit.service
97ms plymouth-read-write.service
85ms systemd-vconsole-setup.service
76ms rtkit-daemon.service
60ms dracut-shutdown.service
51ms check-battery.service
51ms systemd-update-utmp.service
21ms initrd-udevadm-cleanup-db.service
18ms sys-kernel-config.mount
16ms plymouth-quit-wait.service
Quite strange, btrfsmaintenance and lvm2-monitor enabled, although both are
not used. Clearly most time is burned on display-manager and backup of the
rpm-db (could this not be moved to a systemd-timer triggered event at a
later point in time?)
Cheers
Axel
Most of the service you see there aren't they systemd timers that run
because
it was not running during their normal schedule.
Did you try to reboot half an hour after this boot how it behaves ?
Ahrrr tests :-)
I can confirm that the openSUSE boot times on a Raspi 3 are horrendous for
several reasons. I tested and tweaked the unstable tumbleweed images, so take it
with precaution, Leap might behave different:
* It takes quite some time until even grub2 is loaded (u-boot uefi chainload),
but it brings a full grub2 with options to load different kernels or even
distributions. (So for me this is worth the wait)
With which u-boot did you test? I think there were some changes to the
distroboot scripts which might add more device probing before we actually find
and run the grub binary.
* It takes quite along time until the handover (uboot,
uefi -> kernel) is done:
+ u-boot slow at reading the actual files (kernel+initrd)
You mean reading the grub binary. Grub is in charge to load kernel+initrd.
+ a not compressed kernel image (~24MB uncompressed vs
~8MB compressed)
+ a initrd which ships (even after first installation and "mkinitrd") several
kiwi components
Which components do you refer to?
* Always triggered backup-*.timer(s) and mandb-timer
So to cut boot times idid several things:
* remove all kiwi packages -> smaller initrd file
* disable the above mentioned triggers -> this might not be applicable on a
intended stable system
* create and use a kernel with a compressed instead of an uncompressed kernel
image [1].
I'm not sure if we should add this to the kernel build infrastructure, as it is
a RPi3 thing. Thoughts?
With all this done boot times on my raspi 3 from a slow SD card were cut by
around a half (to multi-user console login screen).
[1]:
https://build.opensuse.org/package/show/home:tobijk:kernel/kernel-default
Greetings,
Tobias
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org