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" <[email protected]> >>>> An: "Basil Chupin" <[email protected]>, opensuse-project >>>> <[email protected]> Cc: "nicolas saenz julienne" >>>> <[email protected]> >>>> 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 [email protected] >>> 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: [email protected] To contact the owner, e-mail: [email protected]
