| View previous topic :: View next topic |
| Author |
Message |
flammenflitzer
Advocate
Joined: 25 Nov 2003
Posts: 3532
Location: Berlin
|
 Posted: Sat Aug 15, 2020 5:23 pm Post subject: [erledigt]Bootprezess beschleunigen - firmware + loader |
 |
|
Hallo,
systemd-analyze time | Code: | Startup finished in 19.194s (firmware) + 8.288s (loader) + 2.043s (kernel) + 4.526s (userspace) = 34.053s
graphical.target reached after 4.513s in userspace |
dmesg | grep -i firmware | Code: |
[ 0.598318] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
[ 0.604755] acpi PNP0A08:00: [Firmware Info]: MMCONFIG for domain 0000 [bus 00-7f] only partially covers this bridge |
cat .config | grep CONFIG_FW_LOADER | Code: |
CONFIG_FW_LOADER=y
# CONFIG_FW_LOADER_USER_HELPER is not set
# CONFIG_FW_LOADER_COMPRESS is not set |
Brauche ich firmware + loader?
So, wie ich das sehe wird keine Firmware geladen. Also könnte ich im Kernel CONFIG_FW_LOADER=n und emerge -C sys-kernel/linux-firmware sys-firmware/bluez-firmware sys-firmware/alsa-firmware und damit meine Bootzeit beschleunigen?
Last edited by flammenflitzer on Sun Aug 16, 2020 7:57 am; edited 1 time in total |
|
| Back to top |
|
 |
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5319
|
| Posted: Sat Aug 15, 2020 6:54 pm Post subject: |
|
|
Soweit ich das herausfinden kann ist die zeit für firmware die zeit welche das "Bios" braucht den kernel zu starten.
Zu mindestens laut dem hier: https://github.com/systemd/systemd/issues/8422#issuecomment-374056580
https://github.com/systemd/systemd/issues/8422#issuecomment-374885189
Da hilft es wohl nicht was am kernel zu ändern.
Bei mir sehen die Zeiten so aus:
| Quote: | $ systemd-analyze time
Startup finished in 16.061s (firmware) + 1.169s (loader) + 1.681s (kernel) + 979ms (userspace) = 19.891s
graphical.target reached after 973ms in userspace |
Die Firmware zeit sind bei mir nur 3s schneller. Was bei mir deutlich schneller ist die zeiten für den loader und userspace.
Das System ist ein AMD Ryzen 3900X auf einem MSI X570 Gaming Plus mit 32GB Ram.
Gentoo ist auf einer NVME Samsung SSD 970 EVO 1TB installiert.
Kernel Version: 5.7.11-gentoo
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5319
|
| Posted: Sat Aug 15, 2020 7:18 pm Post subject: |
|
|
Laut dem hier https://wiki.archlinux.org/index.php/Improving_performance/Boot_process
steht wohl loader für den boot loader.
Da die daten für loader bei dir angegeben wird, scheinst du entweder grub oder systemd-boot zu verwenden.
Ich verwende grub2 mit einer hand crafted config und uefi.
Wobei grub2 so installiert wurde das es im standard suchort für uefi binaries (EFI/BOOT/BOOTX64.EFI) liegt. (Via grub-install --removable)
Grund: Auf dem system ist eh nur gentoo installiert ist und dadurch bootet das system auch noch falls durch ein uefi update die boot daten im nvram der firmware verloren gehen sollten.
Hier meine grub.cfg
| Code: | set timeout=1
set default=0
menuentry 'Gentoo Linux (systemd, radeon opensource)' {
insmod part_gpt
insmod all_video
linux /boot/bzImage-5.7.11 root=PARTUUID="<partuuid>" quiet net.ifnames=0 init=/lib/systemd/systemd
initrd /boot/amd-uc.img
} |
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5319
|
| Posted: Sat Aug 15, 2020 9:13 pm Post subject: Re: Bootprezess beschleunigen - firmware + loader |
|
|
Du hattest im anderen Thread gesagt dass gefühlt kubuntu schneller starten würde
Wenn man aber die Zeiten von gentoo
| flammenflitzer wrote: |
systemd-analyze time | Code: | Startup finished in 19.194s (firmware) + 8.288s (loader) + 2.043s (kernel) + 4.526s (userspace) = 34.053s
graphical.target reached after 4.513s in userspace |
|
Mit den Zeiten von kubuntu vergleicht
| flammenflitzer wrote: |
systemd-analyze time | Code: | Startup finished in 21.622s (firmware) + 5.109s (loader) + 3.599s (kernel) + 7.252s (userspace) = 37.584s
graphical.target reached after 7.245s in userspace |
|
startet bei kubuntu das System ca 3.5s langsamer
kubuntu: 37.584s
gentoo: 34.053s
Hier trog das Gefühl.
Wobei systemd wohl nur bis dahin misst bis das graphical target erreicht ist.
Bei mir ist es erreicht wenn sddm erfolgreich gestartet wurde.
(erster subknoten in der ausgabe von systemctl list-dependencies graphical.target
| Code: | -> systemctl list-dependencies graphical.target
graphical.target
● ├─sddm.service
● ├─systemd-update-utmp-runlevel.service
● └─multi-user.target |
Neben blame gibt es auch noch chritical-chain für systemd-analyze.
chritical-chain zeigt die units an welche zum erreichen von graphical.target in abhängigkeit zueinander gestartet werden mussten und wie lange sie brauchten (Dass ist die Zeit was systemd-analyze time ausgibt als "graphical.target reached after <X>s in userspace"
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
| Posted: Sat Aug 15, 2020 10:29 pm Post subject: |
|
|
Ich könnte mir vorstellen, dass die Loader-Zeit einfach durch den timeout-Parameter in Grub Konfigurationsdatei entsteht.
- Bei Firefly ist er auf 1 gesetzt -> 1.169s (loader)
- Bei Kubuntu ist er möglicherweise auf 5 gesetzt (beliebter Wert) -> 5.109s (loader)
- Und könnte es sein, dass er bei flammenflitzer auf 8 steht (oder er hat nach 8 Sekunden Return gedrückt) -> 8.288s (loader)
|
|
| Back to top |
|
|
flammenflitzer
Advocate
Joined: 25 Nov 2003
Posts: 3532
Location: Berlin
|
| Posted: Sun Aug 16, 2020 7:57 am Post subject: |
|
|
Danke an alle. Das mit loader Grub2 gemeint ist habe ich heute gemerkt, als ich eine Minute in der Menüauswahl gewartet habe. Entsprechend verlängert hat sich die Bootzeit. Ich denke, das sich an der Bootzeit nicht viel ändern lässt. Schönen Sonntag.  |
|
| Back to top |
|
|
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5319
|
| Posted: Sun Aug 16, 2020 5:15 pm Post subject: |
|
|
Ich denke zu mindestens an der zeit "+ 4.526s (userspace)" lässt sich eventuell was machen wenn man wüsste welche systemd units da gestartet werden und wie lange sie einzeln brauchen.
Da wäre die ausgabe von systemd-analyze critical-chain hilfreich.
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
flammenflitzer
Advocate
Joined: 25 Nov 2003
Posts: 3532
Location: Berlin
|
| Posted: Mon Aug 17, 2020 12:29 pm Post subject: |
|
|
systemd-analyze critical-chain | Code: |
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 @4.593s
└─sddm.service @4.589s
└─systemd-logind.service @4.104s +477ms <---
└─basic.target @4.095s
└─sockets.target @4.093s
└─dbus.socket @4.092s
└─sysinit.target @4.082s
└─systemd-timesyncd.service @3.554s +514ms <---
└─systemd-tmpfiles-setup.service @3.530s +12ms <---
└─local-fs.target @3.477s
└─home-olaf.mount @3.425s +44ms <---
└─systemd-fsck@dev-disk-by\x2duuid-45f71e3f\x2d754a\x2d4368\x2d90ef\x2d3980ae2596dd.service @2.889s +399ms <---
└─dev-disk-by\x2duuid-45f71e3f\x2d754a\x2d4368\x2d90ef\x2d3980ae2596dd.device @2.820s |
|
|
| Back to top |
|
|
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5319
|
| Posted: Mon Aug 17, 2020 3:59 pm Post subject: |
|
|
Die zeiten schauen soweit gut aus.
Nur was mich stutzig macht, dass schon ~2.8s vergangen sind wenn der erste eintrag in der chain beginnt (dev-disk-by\x2duuid-45f71e3f\x2d754a\x2d4368\x2d90ef\x2d3980ae2596dd.device @2.820s).
Könnte eventuell an folgenden liegen (wie du in deinem m2/nvme thread gepostet hast):
| Quote: | | 2.300s dev-nvme0n1p7.device |
Scheinbar gibt es ein zeitliches Problem mit dem ansprechen/initialisieren des NVME Devices.
Dafür könnte es zwei Gründe geben
1. Ein bug in der SSD Firmware
2. Ein Kompatibilitätsproblem im UEFI mit der NVME device.
Für beides könnte ein Update der SSD/Mainboard firmware das Problem beheben oder zu mindestens stark mindern.
Bei meinem Board gab es z.b. ein Firmware update wo als changelog die verbesserte Kompatibilität für NVME Devices aufgeführt war.
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
|
Deutsches Forum (German)
