• Bearbeitet

Hi,
ich bin dabei meinen Laptop zu verschnellern. Ich habe auf coreboot mit grub als payload gewechselt und könnte bestimmt unter einen 10s boot kommen.
Allerdings macht mir das booten vom Userspace alles kaputt. Auf meinem anderen Laptop hat der maximal 3s gebraucht. Jetzt braucht der bei mir um die 4-5. Ich habe schon mehrere Verbesserungen getätigt und bin mit meinem Latein am Ende.
Anbei die Ausgabe von systemd-analyze critical-chain:

└─multi-user.target @3.854s
  └─getty.target @3.854s
    └─getty@tty1.service @3.853s
      └─systemd-user-sessions.service @3.831s +19ms
        └─network.target @3.804s
          └─iwd.service @3.473s +330ms
            └─basic.target @3.451s
              └─dbus-broker.service @3.324s +123ms
                └─dbus.socket @2.954s
                  └─sysinit.target @2.953s
                    └─systemd-backlight@backlight:intel_backlight.service @3.511s +870>
                      └─system-systemd\x2dbacklight.slice @3.506s
                        └─system.slice @597ms
                          └─-.slice @597ms

Edit: Habe systemd-analyze hinzugefügt

    3n20 meinem Latein am Ende

    so wahnsinnig viel kannst du nicht machen, außer weniger starten, dann gehts schneller 😉

    • Bearbeitet

    Soweit das systemd-analyze critical-chainanzeigt sieht das doch recht gut aus und es startet alles unter 4sec. Deine Rechner haben bestimmt auch unterschiedlich schnelle Hardwarekomponenten. Bei meinem alten ThinkPad R500 mit SSD z.B. benötigt es zum multi-user.target @5.434s.

    3n20 Allerdings macht mir das booten vom Userspace alles kaputt.

    Damit das alte ThinkPad schnurrt bin ich von KDE-Plasma auf Sway umgestiegen. Plasma z.B. braucht doch recht lange beim Start und Sway ist dann auch später bei der Benutzung viel agiler beim Wechsel von Anwendungsfenstern. Ich komme dabei sogar mit 2GB RAM aus, was ja auch die Ladezeiten gering hält. Auf einen Login Manager hab ich dabei verzichtet und log mich auf tty1 ein.

    Ich bin mit dwm unterwegs. und habe X nur in meiner .bashrc als start. Die Zeit sollte also sogar nur bis zum console-login sein.
    (Ich nutze übrigens ein x201 mit SATA-SSD (habe von deadleaf oder wie das heißt auf none umgestellt in der Hoffnung das das was rauskitzelt))
    Meine Hoffnung ist das ich noch mehr in die Zeit nach dem Boot legen kann. Also wesentlich mehr nach dem Login starten.
    Ich weiß aber nicht wie. Ich möchte vor dem Login wirklich nur das allernötigste starten. 😉
    Aber wenn ihr sagt da geht nix mehr, das ist die Hardware am Limit die das ausbremst, dann glaube ich euch da leider auch 😉

    • tuxnix hat auf diesen Beitrag geantwortet.
      • Bearbeitet

      Nach dem login wird es schwierig, weil du dann mit Nutzerrechen arbeitest und dann keine Services vom Nutzer gestartet werden können die Root-Rechte benötigen.
      Mir fallen spontan nur noch diese Möglichkeiten ein da etwas zu beschleunigen:

      • systemctl suspend, systemctl hybrid-sleep oder systemctl hibernate nutzen.
      • Den kernel selbst kompilieren und speziell auf die Maschine und Bedürfnisse abspecken.
      • Ein Arch ohne systemd nutzen - Artix Linux
      • Alpine linux - Kleiner und schneller
      • Bearbeitet

      Komisch, meine Antwort ist weg. Edit: Wurde nur nicht geladen, komisch
      Habe jetzt mit einer anderen grub.cfg in Coreboot etwas rauskitzeln können. Habe alle improvements aus dem Archwiki zu schneler booten gemacht. Ich werde noch ein paar andere Sachen machen wo ich circa weiß was ich tu. Ich gebe dann hier Updates.

      • brikler hat auf diesen Beitrag geantwortet.

        3n20 grub.cfg

        du kannst den kernel auch direkt, vom uefi starten lassen, und eine minimal schlanke intramfs, find ich auch ziemlich sexy^^

          brikler Jep! Dank UEFI braucht man in dem Sinne eigentlich keinen Bootloader mehr.

            brikler
            Leider nein 😉
            Aber mein BIOS ist nur GRUB auf coreboot es ist sogar schneller als direkt EFI und Kernel. Was ich ziemlich peinlich finde für neue Soft- und Hardware.
            Initramfs sind schon ziemlich klein, glaue ich:

            MODULES=(btrfs)
            BINARIES=(/usr/bin/btrfs)
            FILES=()
            HOOKS=(base without-udev autodetect modconf block)
            COMPRESSION=(lz4)

              3n20 HOOKS=(base without-udev autodetect modconf block)

              da geht noch was 😉
              HOOKS="base strip resume"
              …vergiss die nötigen module dann aber nicht ins moudule array zu schreiben

              Dirk in dem Sinne eigentlich keinen Bootloader mehr.

              das ist wahr, praktisch ist er aber doch, wenn man, zb ins multi-users.tager muß, oder einen ausweich kernel benutzen will

              • Dirk hat auf diesen Beitrag geantwortet.

                brikler Das ist natürlich wahr.

                Ich bin auch ganz froh, dass systemd-boot mir ein Menü bietet, so hab ich den Kernel, den LTS-Kernel, und beide mit weiterem (Nvidia-DRM, Microcode, etc.) separat zur Auswahl,. und kann im Zweifelsfall mal wechseln, wenn der Standard-Entry mal nicht zu einem erfolgreichen Boot führt.

                Brauchen tue ich das hingegen allerdings nur extrem selten - und meistens hab ich auch selbst schuld dran 🙂

                Aber zum Thema: das wäre vermutlich auch noch eine Idee: @3n20, welche Boot-Parameter übergibst du? Vielleicht ist da noch Optimierungsspielraum.

                @3n20 es scheint mir, als wärst du ein bruder im geiste 🙂
                wenn du deinen rechner (viel) schneller haben willst, dann benutze NUMA statt SMP, damit kannst du dir sehr, sehr viel zeit fürs stack hin und her kopieren sparen, am bequemsten geht das mit NUMAD …quasi bekommst du damit einen neuen rechner, wenigstens empfand ichs so 🙂

                • GerBra hat auf diesen Beitrag geantwortet.
                  • Bearbeitet

                  brikler quasi bekommst du damit einen neuen rechner, wenigstens empfand ichs so

                  Hast zu diesem Numa weiterführende Links/Literatur? Weil:

                  • auch nach Lektüre des Wikipedia-Artikels erschließt sich mir nicht dein Satz "NUMA statt SMP"
                  • braucht NUMA nicht spezielle Hardware bzw. profitiert am besten davon? (Abschnitt zu ccNUMA im Wikipedia-Artikel)
                  • Ich verstehe auch nicht was dieser numad "macht", das git-Repo hat keine Infos¹. Kann man davon mal ein Logfile/Journal sehen ggf. im Vergleich "ohne numad"?
                  • Im englischen Wiki ergibt eine Suchenach numa prominent die Fundstelle zu mongodb und dortige Nutzung von NUMA.
                    https://wiki.archlinux.org/title/MongoDB#NUMA
                    Dafür müssen aber ja scheinbar die Programme/Prozesse/Services mittels numactl (aus dem gleichnamigen Paket) gestartet werden. Hast du bei dir das Starten von "Software" auch so abändern müssen?

                  @Mods: Falls meine OT-Frage zu Numa hier im Thread "länger" werden sollte kann das gerne abgetrennt werden.

                  //Edit:
                  ¹ Ich habe zumindest die manpage zu numad gefunden...
                  https://linux.die.net/man/8/numad
                  Zumindest die "Description" liest sich für mich jetzt nicht nach "universellem Wundertool" (aka DataBeckers legendärem "Ram-Doubler" scnr<g>), installieren und alles wird super...

                    GerBra ich versuchs mal so gut ichs kann zu erklären 🙂
                    der clou von NUMA ist das: anderen Prozessoren über einen gemeinsamen Adressraum „direkten“ Zugriff darauf gewährt, das spart eine unmenge an kopiererei, und macht damit den rechner um welten agiler.

                    heutzutage hat jedes maiboard eine numaknoten, und das reicht auch, server mit mehreren mainboards, haben natürlich mehr knoten, und da kann mans noch deutlicher spüren.

                    im arch wiki findet sich leider nix, aber im RedHat wik findet sich was zu NUMAD.

                    was NUMA ist
                    NUMA memory prformance
                    Numa policy hit/miss statistics
                    NUMA sorgt dafür, daß es keinen cache miss mehr gibt.

                    was NUMA(D) leisten kann, hab ich mal bem kernel bauen ausprobiert 🙂

                    ohne NUMAD:
                    real	0m7,073s
                    user	0m21,723s
                    sys	0m2,081s
                    mit laufenden NUMAD
                    real	0m4,397s
                    user	0m17,757s
                    sys	0m1,987s

                    4 minuten weniger beim kompilieren, mit dem selben PKGBUILD 🙂

                    • GerBra hat auf diesen Beitrag geantwortet.
                    • GerBra gefällt das.

                      Danke für die Erklärung und Links.
                      Ich habe so gerade numastat und numademo "entdeckt". numastat gibt mir aktuell "Infos" zu einem Node(node0), numademo verlangt nach mindest zwei Nodes. Dann stellt dieser numad dann wohl für das Speichermanagment diese "zusätzlichen" Nodes bereit.
                      Evtl. teste ich das mal irgendwann aus, v.a. ob es für ein "0/8-15"-Desktop System sich auch bemerkbar macht...

                        GerBra Dann stellt dieser numad dann wohl für das Speichermanagment diese "zusätzlichen" Nodes bereit.

                        was numad ist, ist schön im RedHat tuning wiki erklärt 🙂

                        GerBra Evtl. teste ich das mal irgendwann aus, v.a. ob es für ein "0/8-15"-Desktop System sich auch bemerkbar macht...

                        Also ich habe mir mal numad installiert und merke rein garnüscht...

                        Beim Kernelbuild gibt es keinen (auf numad zurückführenden) Unterschied.
                        Ich verwende zum Test folgendes Skript (als User):

                        #wget https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.7.6.tar.xz
                        #tar xvf linux-6.7.6.tar.xz
                        cd linux-6.7.6
                        echo "--> distclean"
                        make distclean
                        echo "--> defconfig"
                        make defconfig
                        echo "--> make vmlinux modules"
                        _start=$(date +%T)
                        /usr/bin/time -p make -j$(nproc) vmlinux modules
                        _stop=$(date +%T)
                        echo "--> finish  Start: $_start Stop: $_stop"

                        Getestet (und jeweils rebootet zwischen den Tests):
                        ohne numad:

                        real 175.67
                        user 1804.21
                        sys 127.52
                        --> finish  Start: 14:54:01 Stop: 14:56:57

                        mit numad:

                        real 171.68
                        user 1758.37
                        sys 126.01
                        --> finish  Start: 15:04:04 Stop: 15:06:56

                        zweiter Lauf ohne numad:

                        real 194.53
                        user 1809.03
                        sys 131.62
                        --> finish  Start: 15:12:27 Stop: 15:15:41

                        Also alles um die 3 Minuten rum (real ist die entscheidende Spalte bei time!).
                        Der 3.Test zeigt, daß es auch immer ein paar Sekunden Differenz geben kann bei gleichen Bedingungen - aber nichts was z.B. beim Lauf mit numad eine signifikante Änderung belegen würde.

                        Bei allen Tests zeigte ein gleichzeitig mitlaufendes:
                        watch --interval 1 numastat
                        nie einen anderen Wert als 0 bei numa_miss
                        Es gab also nie einen Kern/CPU-Thread (bei mir 12) für den einen Numa-Knoten den ich habe, der im Speicherbereich/Cache etwas "vermißt" hätte und etwas umkopieren hätte müssen.

                        Mein Fazit: numad ohne ggf. Hardware mit mehreren Nodes bewirkt auf einem PC rein gar nichts. Evtl. gibt es noch besondere Konfigurations-Optionen (die ich nicht entdeckt habe), aber das alleinige Aktivieren des numad.services bewirkt IMHO nichts.

                        • In Logfiles wird nur das Start/Stop vermerkt
                        • Die einzige aktive Option für den Daemon ist: -i 15 (scannt alle 15s das System)
                        • /var/log/numad.log zeigt(lediglich):
                          Sat Feb 24 15:02:07 2024: Changing THP scan time in /sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs from 10000 to 1000 ms.
                          Sat Feb 24 15:02:07 2024: Registering numad version 20150602 PID 562
                          Sat Feb 24 15:10:27 2024: Shutting down numad

                        Evtl. hattest du bei deinen Tests das build-Verzeichnis nicht vollständig bereinigt, oder Caches nicht geleert. Oder du hast Hardware, die ggf. mehr als nur einen Node hat oder sonstwie davon profitiert.

                        Jedenfalls:

                        brikler …quasi bekommst du damit einen neuen rechner, wenigstens empfand ichs so 🙂

                        kann ich auf keinen Fall nachvollziehen - und ich glaube nicht an "Globuli".

                        • brikler hat auf diesen Beitrag geantwortet.

                          GerBra Also ich habe mir mal numad installiert und merke rein garnüscht...

                          söltsam, sehr söltsam 😉
                          ich hab numad auf zwei nobooks am laufen, beide mit dem selben, positiven ergebnis, der service läuft fehlerfrei?
                          was sagt systemctl status numad? wahrscheinlich nix. warums bei dir nicht mag, keine ahnung…
                          auf jeden fall schade 🙁

                          • GerBra hat auf diesen Beitrag geantwortet.
                            • Bearbeitet

                            brikler der service läuft fehlerfrei?

                            Ja, du kannst mir zutrauen daß ich weiß und überprüfen kann ob ein Service läuft ;-)
                            Auch das numad.log zeigt es ja (ich habe den Verbose-output nicht erhöht, evtl. wird dann mehr geloggt...)

                            Nur zur Referenz: installiert ist bei mir die numad-git Version aus dem AUR, Version 0.5-3

                            Ich habe gerade mal auf meinem Server nachgeschaut:

                            ]# uptime 
                             17:12:48 up 337 days, 23:08,  1 user,  load average: 0,20, 0,19, 0,13
                            # cat /sys/devices/system/node/node0/numastat 
                            numa_hit 21162541487
                            numa_miss 0
                            numa_foreign 0
                            interleave_hit 2281
                            local_node 21161825176
                            other_node 0

                            Dieser hatte in 337 Tagen keinen einzigen numa_miss - wenn dieser Wert bei nur einem Knoten überhaupt aktualisiert wird.

                            Ich halte numad (bzw. jegliche Optimierung des NUMA-Systems) wirklich nur bei Server-Hardware und bestimmten Umgebungen für sinnvoll. Das ist ja auch im Redhat-Wiki zu numad aufgeführt (meiner Meinung nach):

                            numad monitors available system resources on a per-node basis by periodically accessing information in the /proc file system. It tries to maintain a specified resource usage level, and rebalances resource allocation when necessary by moving processes between NUMA nodes.

                            (Fett markiert von mir).
                            //Edit: Nur ein /sys/devices/system/node/ ? "Gefühlter Effekt" == GLOBULI

                            Ebenso siehe dort:
                            numad primarily benefits systems ...
                            numad is unlikely to improve performance ...

                            //Edit2:
                            Mach doch auf einem deiner Rechner mal "meinen" Test von oben (das wget und tar für den 6.7.6 Kernelsource kannst du ja im Terminal ausführen oder einmalig aktivieren), mit und ohne bei dir aktiviertem numad
                            Ob du da einen Unterschied feststellen kannst. Das wäre doch ggf. aussagekräftig.
                            //Edit3: Rebooten nicht vergessen zwischen den Tests!

                            //Edit4: weil ich gerade den Thread nochmal gelesen habe...

                            brikler ohne NUMAD:
                            real 0m7,073s

                            brikler mit laufenden NUMAD
                            real 0m4,397s

                            Einen kompletten Kernel(-PKGBUILD) komplett in 7(sieben) bzw. 4(vier) Sekunden kompiliert? Du mußt einen mörderischen Cluster oder eine große Agency hinter dir haben... ;-)
                            Da waren wohl etliche Teile schon vorkompiliert bzw. das make/makepkg ist einfach zweimal auf einen schon existierende Build losgelassen worden - die Aussagekraft ist dann gleich Null. //Edit: Es sind in deinem o.a. Build-Zeiten auch keine (4)Minuten "Ersparnis", keine der time-Ausgaben enthält bei dir eine Minuten-Ausgabe(0mxx,yyys)