News Für Threadripper & Epyc: AMD und Microsoft arbeiten weiter am Windows-Scheduler

[xexex]

Was soll daran ungewöhnlich sein?
Die Kreuzverbindung von 4 DIE ist eher typisch für ein 4 CPU System, sowohl bei AMD als auch bei Intel, und die Speicheranbindung hängt von der Bestückung ab.

Ungewöhnlich daran war in erster Linie daraus eine CPU zu machen und Rücksicht auf die "mickrige" Speicheranbindung zu nehmen!

Bei einem Intel Numa System hat jede CPU mehrere Speicherkanäle und einen autarken Cache und die Workloads verteilt man möglichst nur auf einzelne Numa Knoten. Serverprodukte wie der SQL Server können mit Numa umgehen und verteilen auch selbsttätig die Datenbanken und den Cache auf die einzelnen Knoten statt Kreuz und Quer alles zu vermischen.

Bei einem Epyc oder TR wurde nun alles anders und einem Numa Knoten "gehören" nur zwei Speicherkanäle oder im schlimmsten Fall gar keine. In "Spezialanwendungen" macht es keinen Unterschied und ein Hyper-V Server würde einfach jede (kleine) virtuelle Maschine zu einem Knoten zuweisen. Leider will weder Epyc noch der TR eine reine CPU für Spezialanwendungen sein und dort fängt dann eben das Problem an.

Im Grunde genommen müsstest du jetzt einen intelligenten "Predictor" im System haben, der erkennt ob eine Applikation viel Bandbreite benötigt, viele Prozesse startet und was und wie dies am besten zu optimieren ist. Ein solches Stück Software hat nun AMD selbst veröffentlicht, aber dies kann nur bedingt den problematischen Systemaufbau kaschieren.

Es wäre halt von Anfang an die beste Lösung gewesen einen zusätzlichen Chip zu nutzen, der alle Speicherkanäle selbst anbindet, mit einem großen L3 Cache bestückt ist und dem System die Aufgabe der Lastverteilung abnimmt. Voila, der IO Chip war geboren!

EDIT: Viel Schwachsinn gelöscht, weil entgegen meiner Vorstellung von so einem Chip, dort kein L3 Cache verbaut zu sein scheint. In meinen Augen gehört auf den Chip ein zentraler L3 oder L4 Cache!

 

[Wadenbeisser]

@xexex
Die Speicheranbindung beim Threadripper ist der Plattform geschuldet denn TR4 kann nicht mehr als 4 Speicherkanäle. Mich hatte beim 2990 WX eher die extrem asymetrische Aufteilung gewundert.
Und wie gesagt, der prinzipielle Aufbau der inter-CPU-Kommunikation ist ein alter Hut und wird schon seit zig Jahren verwendet. Bei einem multi Sockel System bei dem du nicht jeden Speicherkanal mit einem Modul bestückst hast du ebenfalls die gleichen Probleme wie beim Threadripper, das ist also ebenfalls ein alter Hut und eine Abbildung im Sheduler damit schon lange überfällig. Das einzige was wirklich neu ist das ist dass sich das der Aufbau inzwischen auch im Desktop Umfeld eingezogen ist.
Dass diese Probleme ein alter Hut sind und ein Versäumnis seitens Microsofts vorliegt sieht man ja daran dass das Linux Umfeld damit kein Problem zu haben scheint.

 

[xexex]

Bei einem multi Sockel System bei dem du nicht jeden Speicherkanal mit einem Modul bestückst hast du ebenfalls die gleichen Probleme wie beim Threadripper

Keine Frage! Nur ist das ein Fall den man möglichst vermeidet und damit umzugehen weiß. Die wenigsten bauen sich eine Workstation aus zwei CPUs und so gut wie niemand eine aus vier, aber genau dies ist nun mal ein Threadripper. Eine 4 Socket Workstation, bei der jeder CPU nur maximal 2 Speicherkanäle zugewiesen würden. Sowas würde niemand der sich mit solchen Systemen auskennt so bauen.

Natürlich ist die Fabric schneller als Intels UPI/QPI, aber im Endeffekt hate es eben zu den genannten Problemen geführt. Zudem wurden solche Systeme bisher von Profis für Profis speziell zusammengestellt und AMD hat einen Markt betreten in den viele nicht mal das Wort Numa gehört haben.

Letztendlich aber egal, Rome macht vieles richtig, was bisher suboptimal gelöst gewesen ist und ich bin gespannt auf die Ergebnisse.

 

[Wadenbeisser]

@xexex
Bei getrennten Sockeln bei denenn alles nach außen geführt wird hat man mehr Kontrolle darüber aber normalerweise kauft in dem professionellen Umfeld aber auch keiner am Bedarf vorbei, im Desktop Umfeld ist das hingegen eher Alltag. Die Probleme über die wir hier Reden sind schließlich das Ergebnis davon.

Vielleicht war die erste Ryzen Generation eine art Testbalon für das Multi-Chip-Konzept bei dem viele Ansätze getestet wurden und bei dem sich die Kommunikation in einzelnen CPU Kern Modulen über IF bewährt hat(CCX Aufbau), der verteilte Speicherzugriff hingegen nicht.

 

[TheUngrateful]

Solche Dinge gehören vor Release erledigt denn ein Kunde der kauft erwartet das das
... seine volle Leistung entfalten kann - und das beim Kauf, nicht irgendwann in paar Jahren. ^^

So wie Nvidia es mit Raytracing und DLSS vorbildlich vor macht?

 

[anexX]

So wie Nvidia es mit Raytracing und DLSS vorbildlich vor macht?

Ja auch das ist ein Trauerspiel *seufz*.

 

[ottoman]

Das mit Abstand größte Problem des 2990 WX ist sein asymetrischer Aufbau und der Windows Sheduler der damit nichts anfangen / die Last entsprechend verteilen kann.

Bitte mal die verlinkten Artikel lesen. Das Problem liegt nicht am asymmetrischen Aufbau der 24 und 32 Kern Threadripper, da der Epyc unter Windows genauso betroffen ist.
https://www.anandtech.com/show/1385...eadripper-2-performance-and-windows-scheduler
https://level1techs.com/article/unlocking-2990wx-less-numa-aware-apps

Ungewöhnlich daran war in erster Linie daraus eine CPU zu machen und Rücksicht auf die "mickrige" Speicheranbindung zu nehmen!

Bei einem Intel Numa System hat jede CPU mehrere Speicherkanäle und einen autarken Cache und die Workloads verteilt man möglichst nur auf einzelne Numa Knoten. Serverprodukte wie der SQL Server können mit Numa umgehen und verteilen auch selbsttätig die Datenbanken und den Cache auf die einzelnen Knoten statt Kreuz und Quer alles zu vermischen.

Bei einem Epyc oder TR wurde nun alles anders und einem Numa Knoten "gehören" nur zwei Speicherkanäle oder im schlimmsten Fall gar keine. In "Spezialanwendungen" macht es keinen Unterschied und ein Hyper-V Server würde einfach jede (kleine) virtuelle Maschine zu einem Knoten zuweisen. Leider will weder Epyc noch der TR eine reine CPU für Spezialanwendungen sein und dort fängt dann eben das Problem an.

Im Grunde genommen müsstest du jetzt einen intelligenten "Predictor" im System haben, der erkennt ob eine Applikation viel Bandbreite benötigt, viele Prozesse startet und was und wie dies am besten zu optimieren ist. Ein solches Stück Software hat nun AMD selbst veröffentlicht, aber dies kann nur bedingt den problematischen Systemaufbau kaschieren.

Von "problematischen Systemaufbau" würde ich eher nicht sprechen. Das Problem tritt im Windows Scheduler auf, sobald man mehr als 2 NUMA Nodes hat. Soviel haben die Artikel zu dem Thema mittlerweile zu Tage gefördert. Das dürfte also Intel genauso betreffen, zumindest bei Systemen mit mehr als 2 Sockeln.

Ist schon lustig, wie sehr du in den letzten Posts hier mal wieder den Intel Fanboy raushängen lässt und AMD den schwarzen Peter zuschieben willst, obwohl der Fehler ja ziemlich eindeutig bei Microsoft liegt

 

[xexex]

Von "problematischen Systemaufbau" würde ich eher nicht sprechen. Das Problem tritt im Windows Scheduler auf, sobald man mehr als 2 NUMA Nodes hat. Soviel haben die Artikel zu dem Thema mittlerweile zu Tage gefördert. Das dürfte also Intel genauso betreffen, zumindest bei Systemen mit mehr als 2 Sockeln.

Falls du meine Aussage nicht richtig verstanden haben solltest, dieses "Problem" ist bei einem richtigen Numa System eben von keiner so hohen Relevanz. Wenn du ein System mit 4 Sockeln verwendest, hast du im Optimalfall 4 "vollständige" Partitionen im System und Applikationen die nur in Extremfall Speicherzugriffe über diese Grenzen durchführen.

Das ist bei dem Anwedungsfall wie sich AMD es gedacht hat aber nicht mehr der Fall, hier teilt man eben nicht eine CPU und den dazu gehörigen Speicher in mehrere Partitionen und viele Applikationen die damit funktionieren sollen können mit Numa gar nicht umgehen.

Ist Microsoft an dem Problem "Schuld"? Der Scheduler von Microsoft funktioniert seit Jahren so wie er nun mal funktioniert. Dies ist AMD bei der Entwicklung bekannt gewesen und eine Verbesserung von diesem Design wurde mit Rome und Ryzen 3000 nun vorgestellt. Es wäre schön wenn man schon zum Start beides besser zum Laufen gebracht hätte, die "Schuld" kannst du hier allerdings mindestens zu gleichen Teilen auf beide Unternehmen aufteilen.

Auch hier kann ich nur auf ein Beispiel von Intel verweisen, die mit den Stromsparfunktionen von Betriebssystemen unzufrieden waren und vor ein paar Jahren die Stromsparfunktionen komplett in die Hardware vergossen (SpeedShift) hatten.
https://www.anandtech.com/show/9751/examining-intel-skylake-speed-shift-more-responsive-processors

Den Schuldigen zu suchen kann man gerne auch 10 Jahre lang, den Kunden interessiert aber nur, ob die Lösung funktioniert und nicht wer "Schuld" dafür ist, dass sie es nicht tut. Im schlimmsten Fall läuft ein Windows System über 10 Jahre lang so wie es ist und hier würde auch ein schneller Patch von Microsoft wenig helfen, weil er mit Sicherheit nicht Rückwirkend bis Windows 7/Server 2008R2 bereitgestellt wird.

 

[ottoman]

Hast du dir die Artikel über das Thema überhaupt durchgelesen? Es liegt nicht am Aufbau der AMD CPUs (mit den vergleichsweise wenigen direkt angebundenen Speicherchannels pro NUMA Node), sondern am ständigen Wechsel der Nodes durch den Windows Scheduler:

The conclusion was made that in a NUMA environment, Windows’ scheduler actually assigns a ‘best NUMA node’ for each bit of software and the scheduler is programmed to move those threads to that node as often as possible, and will actually kick out threads that also have the same ‘best NUMA node’ settings with abandon. When running a single binary that spawns 32/64 threads, every thread from that binary is assigned the same ‘best NUMA node’, and these threads will continually be pushed onto that node, kicking out threads that already want to be there. This leads to core contention, and a fully multi-threaded program could spend half of its time shuffling around threads to comply with this ‘best NUMA node’ situation.

Quelle: https://www.anandtech.com/show/1385...eadripper-2-performance-and-windows-scheduler

When only one NUMA node is recommended via the “ideal CPU” the windows kernel seems to spend half the available CPU time just shuffling threads between cores. That explains the high-CPU -utilization-but-nothing-gets-done aspect of the low performance. It also means it’s a bit tricky to spot apps/threads that are flailing about this way.

Quelle: https://level1techs.com/article/unlocking-2990wx-less-numa-aware-apps

Aber ja, AMD hätte das vorher wissen müssen und seinen CPUs nicht mehr als 2 NUMA Nodes geben müssen, , damit der fehlerhafte Scheduler in Windows nicht ständig die Threads switcht. Was für eine Logik

 

[chithanh]

Die Speicheranbindung kostet vielleicht ein paar Prozentpunkte an Leistung, aber das ist hier nicht das Problem. Das Problem ist Microsofts Notlösung. Die für 2 NUMA-Nodes noch funktioniert, aber überhaupt nicht mit 4 NUMA-Nodes umgehen kann, und die ganze Zeit damit beschäftigt ist, Threads auf den ersten Die und wieder weg zu schieben.

Es gibt durchaus andere Fälle, wo die Anwendungssoftware (z.B. Euler CFD) oder AMDs Threadripper-Design (z.B. pgbench) versagt, und das Betriebssystem machtlos ist. Aber diesem von Anandtech und Level1techs beschriebenen Fall ist eindeutig allein Microsoft schuld.

 

[Zuckerwatte]

[...]es bringt also nicht die Schuld alleine Microsoft zuzuschieben, wie es manche Foristen immer wieder gerne tun.

Schonmal mit MS zusammengearbeitet? dann weisste wieso....

Es bringt nichts Microsoft in Schutz zu nehmen. Das ist kein Gemeinnütziger Verein.

 

[Cool Master]

Vor allem ist klar bewiesen das es an MS liegt. Das ist halt so bei Closed Source Software.

 

[xexex]

Hast du dir die Artikel über das Thema überhaupt durchgelesen? Es liegt nicht am Aufbau der AMD CPUs (mit den vergleichsweise wenigen direkt angebundenen Speicherchannels pro NUMA Node), sondern am ständigen Wechsel der Nodes durch den Windows Scheduler:

Das eine hängt mit dem anderen aber zusammen...... Das was du verlinkt hast, ist nichts anderes als das was ich bereits gesagt habe!

In einem "echten" Numa System, hat man die Systeme entsprechend gestaltet. Ich betreue eine grössere dreistellige Zahl an Servern mit Dual Socket Systemen, wenn dort mehrere VMs drauf laufen, dann hat keine dieser VMs mehr vCPUs zugewiesen, als ein Numa Node liefern könnte. Die Ausnahmen in diesem Fall sind einzig Datenbankserver, Microsoft SQL kann wunderbar mit Numa umgehen.

Diese Konfiguration hat noch nie zu irgendwelchen Problemen geführt und wenn eine VM komplett ausgelastet ist, dann liegen alle Prozesse dieser VM auf einer einzigen CPU und somit in einem einzelnen Numa Node und werden auch nicht zwischen Nodes hin und her geschaltet.

Diese Fall liegt aber bei den AMD CPUs nur in den seltensten Fällen vor. Hier will man sogar, dass verschiedene Nodes genutzt werden um überhaupt die volle Speicherbandbreite zur Verfügung zu haben. Umgekehrt muss man aber einen Coreswitch vermeiden, weil dann alle Daten aus dem Cache verloren gehen und dieser vergleichsweise ewig dauert.

An dieser Stelle liegt eben das Problem. Im "optimalen" Fall verwenden die Applikationen nie mehr Threads als ein Die zur Verfügung hat, das System lässt diese Threads auf diesem Die und nutzt nur den direkt angebundenen Speicher dort. Das funktioniert bei AMD wunderbar wenn ein Hoster zig kleine Webserver hostet, aber eben nur dort.

Das System hat über Jahre hinweg auch wunderbar funktioniert, unter anderem weil man nicht versucht hat mit Numa in Märkte vorzustoßen die davon keine Ahnung haben und weil die bisherigen CPUs einen sehr einheitliche und homogenen Aufbau hatten. Ein Switch von Kern zu Kern kostet bei Intel nur einen Bruchteil der Zeit und alle Kerne eines Sockels teilen sich einen gemeinsamen L3 Cache.

Das Problem liesse sich teilweise mit einem besseren Scheduler lösen, hier liegt die Schuld bei Microsoft und nur die können versuchen den Scheduler zu optimieren oder ähnlich dem Linux Scheduler gestalten. Es bleibt aber ein Workaround und das eigentliche Problem kriegst du nur mit einer besseren Architektur wie Rome oder Ryzen 3000 vollständig gelöst.

Hätten alle Kerne und Dies auf der AMD Plattform einen gemeinsamen L3 oder L4 Cache, wären die Kosten für einen Coreswitch wesentlich geringer und das Problem hätte es in dieser Form gar nicht erst gegeben. An diesem Punkt liegt die Schuld eben bei AMD, weil sie durchaus wussten wie der Windows Scheduler funktioniert und die Hardware trotzdem so gestaltet haben wie sie nun mal ist.

Wie ich bereits gesagt habe, interessiert es den Kunden am Ende aber wenig, er will nur eine funktionierende und performante Lösung.

 

[ottoman]

Nichts für ungut, aber du hast nicht wirklich verstanden, was in den Artikeln steht. Systeme mit nur 2 NUMA Nodes sind überhaupt nicht betroffen. Von daher ist dein Beispiel überhaupt nicht von Belang.

Das Problem ist das permanente Verschieben der Threads. Ausgelöst durch einen Bug im Windows Scheduler. Das kostet immens viel Leistung und da geht jedes System in die Knie, ganz egal wie es aufgebaut ist.

 

[ottoman]

Das System hat über Jahre hinweg auch wunderbar funktioniert, unter anderem weil man nicht versucht hat mit Numa in Märkte vorzustoßen die davon keine Ahnung haben und weil die bisherigen CPUs einen sehr einheitliche und homogenen Aufbau hatten. Ein Switch von Kern zu Kern kostet bei Intel nur einen Bruchteil der Zeit und alle Kerne eines Sockels teilen sich einen gemeinsamen L3 Cache.

Das Problem liesse sich teilweise mit einem besseren Scheduler lösen, hier liegt die Schuld bei Microsoft und nur die können versuchen den Scheduler zu optimieren oder ähnlich dem Linux Scheduler gestalten. Es bleibt aber ein Workaround und das eigentliche Problem kriegst du nur mit einer besseren Architektur wie Rome oder Ryzen 3000 vollständig gelöst.

Hätten alle Kerne und Dies auf der AMD Plattform einen gemeinsamen L3 oder L4 Cache, wären die Kosten für einen Coreswitch wesentlich geringer und das Problem hätte es in dieser Form gar nicht erst gegeben. An diesem Punkt liegt die Schuld eben bei AMD, weil sie durchaus wussten wie der Windows Scheduler funktioniert und die Hardware trotzdem so gestaltet haben wie sie nun mal ist.

Wie ich bereits gesagt habe, interessiert es den Kunden am Ende aber wenig, er will nur eine funktionierende und performante Lösung.

Mal angenommen, so ein Switch von Kern zu Kern kostet nur noch sehr wenig Zeit. Was glaubst du denn, passiert in der nun freien Zeit? Dann wird einfach öfter gewechselt! Bringt also nichts. Genau das ist ja das Problem des Windows Schedulers. Da ist die Architektur egal.

Mit xexex zu Argumentieren ist sinnlos. In seiner Religion sind Microsoft und Intel Götter und dem Glauben nach unfehlbar. Und jemand, der einen Glauben hat, interessiert sich nicht für Fakten die seinem Weltbild widersprechen.
TR ist die Schlange, die die Menschheit in Versuchung führt obwohl sie der Botschafter Satans persönlich ist. Eigentlich meint er es nur gut mit uns, seiner Ansicht nach. Steht irgendwo hier was zu TR ist auch xexex zur Stelle, um die Leute für die gute Seite zurückzugewinnen.

Das ist leider auch meine Erfahrung. Bei AMD wird jede Mücke zum Elefanten und bei Intel wird selbst der größte Bullshit mit den abenteuerlichsten Argumenten verteidigt.

 

[xexex]

Das Problem ist das permanente Verschieben der Threads. Ausgelöst durch einen Bug im Windows Scheduler. Das kostet immens viel Leistung und da geht jedes System in die Knie, ganz egal wie es aufgebaut ist.

Dann lies dir deinen verlinkten Text noch einmal in Ruhe durch!

When running a single binary that spawns 32/64 threads, every thread from that binary is assigned the same ‘best NUMA node’, and these threads will continually be pushed onto that node, kicking out threads that already want to be there

Das passiert dir bei einem normalen Numa Aufbau nicht, weil es dort nicht vorkommen sollte, dass mehrere Applikationen um die gleichen Ressourcen kämpfen.

In meinem Beispiel habe ich dir es bereits genannt. Wenn bei mir auf einem Dual Sockel System zwei VMs laufen, dann läuft jede davon auf einem einzelnen Numa Node und keine davon wird ohne Grund auf einen anderen Node geschoben.

Das "Problem" was im Text genannt wurde tritt dann auf, wenn du eine Applikation hast die mit Numa nichts anzufangen weiss und die 32 Threads startet und somit eigentlich 4 Numa Nodes belegt. Ob du jetzt ein 2,4 oder 8 Sockel System nimmst oder eine CPU die in 8 Numa Nodes aufgeteilt ist, ist dabei unerheblich.

Das Problem würdest du genauso haben, wenn du ein 4 Sockel Xeon System nehmen würdest und dort eine "normale" Applikation mit mehreren Threads ausführst. Jeder der sich mit solchen Systemen auskennt, würde so einen Aufbau vermeiden.

Ein SQL Server besitzt nicht umsonst eine genaue Steuerung für solche Fälle und das gleiche gilt für alle anderen Applikationen die für solche Systeme gestaltet wurden.

Mal angenommen, so ein Switch von Kern zu Kern kostet nur noch sehr wenig Zeit. Was glaubst du denn, passiert in der nun freien Zeit? Dann wird einfach öfter gewechselt! Bringt also nichts. Genau das ist ja das Problem des Windows Schedulers. Da ist die Architektur egal.

Der Switch von Kern zu Kern wird bei allen Systemen ständig durchgeführt, oder was glaubst du wieso eine Applikation mit einem zu 100% ausgelasteten Thread auf einem 4C System so aussieht, als würde sie auf allen Kernen laufen und nur jeweils 25% der Leistung nehmen? Ein Scheduler schaltet hunderte Prozesse in der Sekunde ständig hin und her, so funktioniert nun mal ein "multitasking" System.

Das ist unter Linux übrigens nicht wesentlich anders, hier werden aber anscheinend stark ausgelastete Prozesse für eine erheblich längere Zeit auf einem einzelnen Kern behalten.

EDIT: Hier mal ein Beispiel von unserem 8C SQL Server

Es finden während der Laufzeit schlappe 5tsd Kontextwechsel in der Sekunde statt (40% Auslastung derzeit), das ist kein "Bug" sondern ein ganz normaler Vorgang.

 

[ottoman]

Der (mal wieder) viel zu lange Beitrag hat leider wenig mit dem Thema zu tun. Aber das hier ist der springende Punkt:

Das "Problem" was im Text genannt wurde tritt dann auf, wenn du eine Applikation hast die mit Numa nichts anzufangen weiss und die 32 Threads startet und somit eigentlich 4 Numa Nodes belegt. Ob du jetzt ein 2,4 oder 8 Sockel System nimmst oder eine CPU die in 8 Numa Nodes aufgeteilt ist, ist dabei unerheblich.

Das Problem würdest du genauso haben, wenn du ein 4 Sockel Xeon System nehmen würdest und dort eine "normale" Applikation mit mehreren Threads ausführst. Jeder der sich mit solchen Systemen auskennt, würde so einen Aufbau vermeiden.

Lässt tief blicken, wie du das hier herunterspielst und "Problem" sogar noch in Anführungszeichen setzt... Aber genau um dieses Problem geht es doch hier die ganze Zeit. Im Artikel von level1techs wurde untersucht, warum ein Rendering Tool (Indigo) so ein seltsames Verhalten gezeigt hat. Die Antwort: wenn ein Programm sich alle Threads schnappt und das System mehr als 2 NUMA Knoten hat, wechselt der Windows Scheduler wie wild die Threads auf den Kernen und die Performance geht in den Keller. Nur Windows zeigt dieses Verhalten. Die logische Schlussfolgerung: ein Bug im Windows Scheduler.

Hat das was mit der Architektur des Prozessors zu tun, abseits der Anzahl der NUMA Knoten? Nein.
Sind auch Intel Systeme davon betroffen? Höchstwahrscheinlich ja.
Wird von dir trotzdem wieder ohne Ende gegen AMD geschossen (größtenteils am Thema vorbei) und denen die Schuld bzw. Teilschuld gegeben? Definitiv ja.

Wenn bei mir auf einem Dual Sockel System zwei VMs laufen [...]

Warum fängst du denn schon wieder mit deinen Dual Sockel Systemen und irgendwelchen VMs oder SQL Servern an? Die betrifft es doch gar nicht.

Jeder der sich mit solchen Systemen auskennt, würde so einen Aufbau vermeiden.

Das sagst du als was? Als Server-Admin? Sorry, aber warum sollte man es vermeiden, ein Rendering Programm auf einer Multi Socket System laufen zu lassen? Scheint ja offensichtlich sehr viel Renderzeit zu sparen, zumindest unter Linux. Ich sehe auch kein Problem darin, wenn ein Render Tool nichts mit NUMA anfangen kann. Denn jeder Thread arbeitet ja nur an einem kleinen Teil des Bilds.

Der Switch von Kern zu Kern wird bei allen Systemen ständig durchgeführt [...]

Sollte hinlänglich bekannt sein. Passiert unter Windows häufiger als unter Linux. Komisch wird es nur, wenn damit die Hälfte der Rechenzeit verschwendet wird, was wohl auf ein paar Millionen Switches pro Sekunde hinausläuft.

 

[xexex]

Lässt tief blicken, wie du das hier herunterspielst und "Problem" sogar in Anführungszeichen setzt... Aber genau um diese Problem geht es doch hier die ganze Zeit! Im Artikel von level1techs wurde untersucht, warum ein Rendering Tool (Indigo) so ein seltsames Verhalten gezeigt hat. Die Antwort: wenn ein Programm sich alle Threads schnappt und das System mehr als 2 NUMA Knoten hat, wechselt der Windows Scheduler wie wild die Threads auf den Kernen und die Performance geht in den Keller. Nur Windows zeigt dieses Verhalten. Die logische Schlussfolgerung: ein Bug im Windows Scheduler.

Du beschreibst das Problem durchaus genau, nur mit deiner Schlussfolgerung werde ich nicht warm.

Numa wurde nicht für den von dir genannten Einsatzzweck entwickelt und jede Numa Applikation wüsste mit diesem Problem umzugehen!

Eine Applikation die für solche Systeme entwickelt wird, kennt Numa und würde beim Rendering im Optimalfall schlichtweg die Aufgaben auf zwei Numa Nodes aufteilen und nicht versuchen einfach so viele Threads wie möglich ohne sie selbst zu gruppieren auf das System loszulassen.

Im Gegensatz zu einer Applikation, die ganz genau weiß was sie gerade machen möchte und den Workload auf zwei oder beliebig viele Numa Gruppen aufteilen könnte, kennt ein Scheduler diese Anforderungen nicht! Microsoft verhält sich hier so wie es sich bisher mit Numa Aware Applikationen verhalten hat. Der Scheduler geht davon aus, dass die Applikation die Threadanzahl an das System anpasst und versucht die Threads auf dem "best NUMA node" zu halten und dies war bevor Epyc auf den Markt kam fast immer auch Best Practice.

Ein SQL Server wird automatisch die Anzahl der Threads genau an die Größe des Numa Nodes anpassen oder er wird so konfiguriert, dass er es tut!

https://docs.microsoft.com/de-de/sq...ver-configuration-option?view=sql-server-2017

Ja der Scheduler von Microsoft arbeitet nicht optimal mit AMDs aktuellen Prozessoren, das rührt aber schlichtweg daher, dass ein solcher Aufbau nie für den Markt angedacht war, in den AMD nun mit ihren 4-8 Numa CPUs rein wollte.

Du kannst es gerne Bug nennen, nur ist es dadurch keiner. Es war schlichtweg bisher nie die Aufgabe des Schedulers, die Unzulänglichkeiten von nicht Numa Aware Applikationen auf solchen Systemen auszugleichen. Es ist möglich, dass man dies irgendwann mal speziell für AMDs aktuelle CPU Generationen optimieren wird, nun hat aber AMD mit Rome und Ryzen 3000 selbst das gemacht, was sie von Start an hätten machen sollen, dann wäre das Problem gar nicht erst entstanden.

Sich auf "andere" zu verlassen um die Probleme der eigenen Architektur umzuschiffen, hat schon bei GCN nicht wirklich geklappt. Vom Prinzip ist das "Problem" hier gleich gewesen - eine Hardware die mit der vorhandenen Software suboptimal funktioniert.

 

[MK one]

@ottoman
Lass ihn , er ist ein LCC Admin , für xexex muß ein Server Prozessor einen möglichst hohen Takt haben und bei ihm ist Windows das Betriebssystem seiner Wahl ....
Bei ihn läuft ein Dual Socke 8C Xeon noch als wünschenswerte Konfiguration ...

Bei AMD wird mit dem Ryzen 3xxx ein 16C bereitsauf der Mainstream Plattform Platz finden ..

Das ist nicht die Zielgruppe die AMD mit Naples ansprechen wollte , da wollte man die Datacenter ansprechen , möglichst Effizient mit vielen Kernen . Beim Rome sind die 4 Numa Nodes Geschichte dank I/O Die , der 64C Rome wäre trotzdem nichts für ihn , da nur 1,9 / 2.0 Ghz Takt .

 

[xexex]

Bei ihn läuft ein Dual Socke 8C Xeon noch als wünschenswerte Konfiguration ...

Das rührt einfach daher, dass wir zu 90% Kunden aus dem SMB Bereich betreuen und hier sind (Lizenz) kosten nicht irrelevant und 32 Kerne Perlen vor die Säue.

Der Punkt ist allerdings, dass AMD eigentlich vom Start an diesen Markt auch bedienen wollte, aber leider bis heute nicht geliefert hat.

Niemand bestreitet, dass AMD CPUs in Datencenter einen Platz sicher haben. Das nutzt mir nur mit der bisherigen Architektur herzlich wenig.

Auf Rome bin ich gespannt und mir ist die Farbe letztendlich auch egal. Unser eigenes RZ startete einst auf AMD Basis nur leider ist das schon einige Jahre her und nun fristet nur noch eine einzige AMD CPU ihr einsames da sein, in einem NAS System.