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)

          @GerBra ich hab absolut keine ahnung, wie time auf dieses ergebnis kommt, zugegeben, es war blos ein localmodconfg, die stellen sind schlicht und einfach falsch, und ja, es war zwei mal mit einem leeren buldverzeichnis.

          ich hab grad noch mal expermentet:

          mit `NUMAD`
          real	29m56,863s
          user	215m39,600s
          sys	13m10,465s
          ohne `NUMAD`
          real	30m4,243s
          user	212m31,098s
          sys	12m54,027s
          mit `numactl --interleave=all`
          real	28m13,598s
          user	204m17,636s
          sys	12m14,744s

          3n20 Ich möchte vor dem Login wirklich nur das allernötigste starten.

          Dazu ist mir noch eingefallen, dass die Dienste gestaffelt gestartet werden. Man könnte zum Beispiel den Start vom iwd.service hinter das Einloggen legen indem man den bisherigen Eintrag After=network-pre.targetin After=network-pre.target getty@tty1.serviceabändert.
          Der Befehl systemctl edit --full iwd.service ist zum editieren am praktischsten.
          Bei systemd-analyze critical-chain hat mir das 500ms eingebracht.

          Um zu klären welcher Dienst von was abhängig ist wäre vor einer Änderung ein systemctl list-dependencies <xxx>.servicezu empfehlen.

          • brikler hat auf diesen Beitrag geantwortet.

            tuxnix Man könnte zum Beispiel den Start vom iwd.service hinter das Einloggen

            das macht das kraut nicht fett 😉
            wenn man iwd aus dem weg haben möchte, weil man ihn ja erst später braucht, würde ich ihn mit einen timer starten, oder den service type auf idle ändern.

            • tuxnix hat auf diesen Beitrag geantwortet.
              • Bearbeitet

              brikler das macht das kraut nicht fett 😉

              Das Kraut soll dabei auch gar nicht in die Höhe schießen 😉
              Ein zusätzlicher Timer. Hmm?

              • brikler hat auf diesen Beitrag geantwortet.

                tuxnix Ein zusätzlicher Timer.

                so, oder den type inidle ändern, beides ist kaum aufwand 🙂

                Wenn ein Service erst nach dem Anzeigen des Anmeldeprompts oder wirklich erst nach dem einloggen gestartet wird, hat er keinen direkt Einfluss mehr auf den Bootvorgang.