NUMA Nodes per Socket

[ArilethDeTyr]

1. Nenne uns bitte deine aktuelle Hardware:
(Bitte tatsächlich hier auflisten und nicht auf Signatur verweisen, da diese von einigen nicht gesehen wird und Hardware sich ändert)

• Prozessor (CPU): AMD Ryzen 9 5950X
• Arbeitsspeicher (RAM): 2 x 16 GB DDR4-3200 MHZ
• Mainboard: GIGABYTE X570S UD
• Grafikkarte: Geforce RTX 3080 10GB
• HDD / SSD: 2 x Samsung NVMe 1 GB / SATA-SSD 512 GB
• Aktuelles BIOS

Ich habe versucht, die "NUMA Node per Socket" (NUMA0 bis NUMA8) zu konfigurieren und den L3-Cache als separaten NUMA-Node zu deaktivieren. Nachdem ich NUMA0 als verwendeten Node eingestellt und die Option "L3 als separaten NUMA-Node" deaktiviert habe, startet Windows 11 zwar noch, aber im Geräte-Manager wird keine CPU mehr angezeigt. Es scheint, als sei der Knoten, auf dem die CPU sitzt, komplett verschwunden.

Welche Konfiguration wäre sinnvoll?
NUMA wird ja oft bei virtuellen Maschinen (VMs) und Workstations genutzt, die für Video-Bearbeitung und 3D-Design verwendet werden. Aber wie sollte man NUMA optimal für Gaming konfigurieren? Ich möchte vermeiden, dass durch eine falsche Einstellung die Leistung sinkt oder Probleme auftreten. Der Ryzen 9950X hat der zwei CCDs ? Dann wäre 2 NUMA per socket vielleicht besser? Ich kann es auch nirgends auslesen was auto setzt.

Und was ist mit dem L3 als separaten NUMA Node, ist das gut?

Ich habe 3DMark Benchmarks ausgeführt und keinen signifikanten Unterschied bemerkt.

Wisst ihr vielleicht mehr?

MFG Manu

 

[Khorneflakes]

Für diesen Anwendungsfall ist NUMA völlig irrelevant und du musst nichts einstellen.

 

[Humptidumpti]

Ganz einfach da nix anfassen. Afaik hat die Kiste keine multiplen numa nodes. Das gibt es bei Threadrippern und Epyc Prozessoren.

 

[Ray519]

Bei NUMA geht es traditionell um den Speicher.

Die alten Ryzens mit mehreren Dies, wo jeder Die einen Memory Controller hatte waren zB NUMA in Hardware. Weil der eine Die hat nur Zugriff auf seine eigenen DIMMs und muss mit dem anderen Die reden für die anderen DIMMs, die letztendlich nach Speicheraddressen aufgeteilt werden müssen. Und die Kommunikation mit einem entfernten Speichercontroller ist langsamer als den lokalen zu verwenden.

Das trifft aber auf die aktuelle Hardware nicht mehr zu.

Der eigentliche Speicher ist immer gleich weit weg und hängt eh immer am IO Die.

Das einzige was hier nicht einheitlich ist, ist die Core-to-Core latency wegen den Caches.

Das heißt die eigentlichen Dinge für die das OS optimiert treffen nicht zu und es braucht eh andere Modellierung. Das OS kann den CCX wechseln wenn es möchte. Es kostet nur einmal Latenz proportional zu wie viel im alten CCX gecached ist. Genauso wie es Latenz kostet wenn zwischen 2 Kernen gewechselt wird. Proportional zu wie viel im L1 und evtl. L2 gecached war und jetzt neu gecached werden muss.

Während bei einem echten NUMA System jeder Speicherzugriff gnadenlos langsamer wäre, bis er mit manuellen Kopieraktionen zum lokalen Speicher kopiert wurde. Der Cache ist dabei das kleinste Problem und Cache Kohärenz Latenzen gibt es immer. Intel mit seinem Ringbus hat ja zB auch unterschiedliche Latenzen zwischen allem. Der L3 ist hier halt hintendran und zwischen Speicher und Ringbus anstatt das Gruppen von Cores jeweils eigenen L3 Cache haben.

 

[ArilethDeTyr]

@Ray519 Danke, das hat mich jetzt gut abgeholt, mit dieser Erklärung kann ich was anfangen.

MFG Manu

Ergänzung (11. Dezember 2024)

Bei NUMA geht es traditionell um den Speicher.

Die alten Ryzens mit mehreren Dies, wo jeder Die einen Memory Controller hatte waren zB NUMA in Hardware. Weil der eine Die hat nur Zugriff auf seine eigenen DIMMs und muss mit dem anderen Die reden für die anderen DIMMs, die letztendlich nach Speicheraddressen aufgeteilt werden müssen. Und die Kommunikation mit einem entfernten Speichercontroller ist langsamer als den lokalen zu verwenden.

Das trifft aber auf die aktuelle Hardware nicht mehr zu.

Der eigentliche Speicher ist immer gleich weit weg und hängt eh immer am IO Die.

Das einzige was hier nicht einheitlich ist, ist die Core-to-Core latency wegen den Caches.

Das heißt die eigentlichen Dinge für die das OS optimiert treffen nicht zu und es braucht eh andere Modellierung. Das OS kann den CCX wechseln wenn es möchte. Es kostet nur einmal Latenz proportional zu wie viel im alten CCX gecached ist. Genauso wie es Latenz kostet wen zwischen 2 Kernen gewechselt wird. Proportional wie viel im L1 und evtl. L2 gecached war und jetzt neu gecached werden muss.

Während bei einem echten NUMA System jeder Speicherzugriff gnadenlos langsamer wäre, bis er mit manuellen Kopieraktionen zum lokalen Speicher kopiert wurde. Der Cache ist dabei das kleinste Problem und Cache Kohärenz Latenzen gibt es immer. Intel mit seinem Ringbus hat ja zB auch unterschiedliche Latenzen zwischen allem. Der L3 ist hier halt hintendran und zwischen Speicher und Ringbus anstatt das Gruppen von Cores jeweils eigenen L3 Cache haben.

Mit der Einrichtung von zwei zusätzlichen NUMA-Nodes für die beiden separaten L3-Caches könnte man das Betriebssystem bzw. den Task-Scheduler dazu zwingen, Prozesse nur innerhalb eines zusammenhängenden CCX auszuführen und zu vermeiden, Threads auf einen anderen CCX zu verlagern. Allerdings ist dies mit Windows 11 nicht mehr notwendig, da der Scheduler bereits so optimiert ist, dass Threads bevorzugt innerhalb eines CCX bleiben und unnötige Wechsel zwischen CCXs vermieden werden. Daher ist die künstliche Einrichtung von NUMA-Nodes in diesem Szenario überflüssig.

Ist das so richtig?

 

[Ray519]

Prozesse nur innerhalb eines zusammenhängenden CCX auszuführen und zu vermeiden

Vllt. Aber eben nur als Nebeneffekt. Und das OS denkt dann vllt das es tatsächlich Daten hin und her kopieren müsste und 2 getrennte Speicherfülltstände hätte, je einen pro Node. Oder so seltsames Zeugs wie dass der gesamte Speicher nur an einem der beiden NUMA Nodes hängt und der andere Node grundsätzlich zu vermeiden ist deshalb.

Oder das OS ist schlau genug, dass es versteht, dass der Speicher gar nicht NUMA ist und ignoriert das alles dann.

Du siehst, die NUMA Modellierung passt nicht. Alles was übrig bleibt ist runmprobieren, ob deine Lasten mit der einen oder anderen Option besser gehen. Aber da die Haupteigenschaft der Optionen keinen Sinn macht oder zu Fehlentscheidungen führt, ist das nicht wirklich abzusehen was für Konsequenzen die verschiedenen Optionen denn haben werden.

Und mein Punkt war, dass ein modernes OS grundsätzlich solche Core-to-Core Latenzen und Interconnects and Caches berücksichtigen sollte für maximale Performance. Und da ist es nur halt eben anderes als was man viel von Intel gewohnt war bis dahin. Aber das ist dann auch viel worauf Optimierungen abziehlen. Genau wie es jetzt für Arrow Lake einige Optimierungen braucht, weil die Faustregeln, die überall eingebaut sind eben nicht mehr zutreffen. Und es gibt immer Programme die das selbst in die Hand nehmen und das Default-Verhalten vom OS überschreiben um bessere Ergebnisse zu bekommen. Die müssen dann aber auch immer gepflegt werden mit solchen neuen Dingen.

Die Idee bei NUMA ist, dass du einer Speicheradresse ansehen kannst, von welchem Node sie kommt und die Hardware die Daten finden kann, egal wie weit weg. Es ist also kein technischer Grund warum du Threads nicht auf verschiedene Nodes packen kannst. Das OS versucht es nur zu tracken und standardmäßig zu verhindern, weil es massiv Performance kosten würde für die meisten Programme. (Aber ein NUMA-Aware Programm könnte zB wissen, dieser Thread hat seine eigenen Daten. der Kommuniziert kaum mit anderen Threads, den kann man wunderbar auf einen eignen NUMA Node packen).
Und genau so einen Kram machen OS und Spiele schon überall von sich aus. Das heißt das ist absolut unberechenbar. Und über die Hardware zu lügen hat statistisch mehr Probleme als es hilft für das gesamte Spektrum an Software.