Fragen zum Windows Task Switching und Power Management

[DeathAndPain2 10]

Hallo allerseits,

 

es gibt da ein Thema, das mich schon seit geraumer Zeit beschäftigt und das ich hier gerne mal diskutieren würde:

 

Wie wirkt sich eigentlich das automatische Verschieben von Tasks auf andere Prozessorkerne auf das Power Management des Computers aus?

 

Der Hintergrund meiner Frage ist, dass Windows anscheinend sehr unvernünftig mit Tasks umgeht, die selbst nicht weiter parallelisierbar sind, aber einen Kern voll auslasten. Windows sieht dann, dass ein Kern auf 100% steht, während die übrigen Kerne bei 0% dümpeln. In der Hoffnung, eine gleichmäßigere Auslastung zu erreichen, verschiebt Windows den Task auf den nächsten Kern, aber dann steht der bei 100% etc. So saust der Task im Milli(micro?)sekundenbereich von Kern zu Kern, was in den Performancegraphen des Taskmanagers zu der Illusion führt, alle Kerne seien in etwa gleich ausgelastet.

 

Das führt aber dazu, dass der jeweils aktive Kern hoch- und wieder heruntergetaktet werden muss, in einem Bereich von Millisekunden. Der Phenom I kann alle Kerne separat einstellen und saust hier vermutlich (habe selber keinen, hab es nur gelesen) auch mit der Spannung in Sekundenbruchteilen hoch und runter.

 

Ich frage mich, ob dieses sinnlose Systemverhalten nicht auf die Performance schlägt. Ist es performancemäßig wirklich verlustfrei, einen Task auf einen anderen Kern zu schieben? Und kostet das ständige Umschalten der Power States der Prozessorkerne nicht auch mehr Energie?

 

Beim Phenom I kostet es auf jeden Fall Performance, weswegen AMD die einzelne Ansteuerbarkeit der Kerne hinsichtlich des Power Management beim Phenom II wieder abgeschafft hat. Eigentlich hatte ich gelesen, dass beim Phenom II alle Kerne auf 100% laufen, wenn nur einer voll ausgelastet ist. Nachdem ich jetzt aber selber einen habe und diesen mit dem AMD Power Monitor überwacht habe, konnte ich feststellen, dass die inaktiven Kerne weiterhin auf 800 MHz runtergetaktet werden. Nur die Kernspannung bleibt für alle Kerne auf dem Maximum, wenn einer unter Volllast läuft.

 

Als Anwender kann man hierauf wohl nur reagieren, indem man solche Einkernanwendungen manuell (über den Task Manager oder die LAUNCH.EXE) fest an einen Kern bindet. Allerdings habe ich ein Programm, das selbst einen anderen Einkerntask startet, so dass LAUNCH.EXE nicht in Frage kommt, und jedesmal nach Programmstart den Task Manager zu bemühen ist nicht wirklich komfortabel. (Kennt jemand einen Weg, einen bereits laufenden Task per Batchfile an einen Prozessorkern zu binden?)

 

Letztlich frage ich mich, ob sich die Taskverwaltung in Windows nicht besser hätte programmieren lassen. Wäre es nicht machbar, dass das Betriebssystem erkennt, wenn ein Task einen Kern zu 100% auslastet und dann von Kern zu Kern saust? XP macht das so, Vista macht das so, und das neue Windows 7 auch. Aber sowas kann doch nicht effizient sein.

 

Bei Intel-Prozessoren der iCore-Reihe soll das nicht vorkommen, weil die inaktive Kerne per Power Gate komplett abschalten. Zumindest habe ich das gelesen, ohne selber einen Intel-Prozessor zu besitzen. Allerdings kommt mir das recht unglaubwürdig vor. Denn Windows soll die inaktiven Kerne bei Bedarf ja auch nutzen können und muß sie daher als verfügbar ansehen. Drum würde ich erwarten, dass solch Task auch bei einer Intelmaschine von Kern zu Kern rast, wobei die Kerne dann in Sekundenbruchteilen ein- und wieder ausgeschaltet werden. Auch das kann unmöglich performant oder energieeffizient sein IMHO.

 

Das Ganze kommt mir so undurchdacht und sinnlos vor, dass ich gerne weitere Informationen oder Meinungen zu dem Thema hören würde.

[zahni 524]

Iwe kommst Du darauf, dass Windows Prozesse von einem Kern zum Anderem schiebt ? Windows hat sicher was besseres zu tun.

 

Prozesse werden auch nichgt direkt ausgeführt, sondern Threads. Ein Prozess hat immer mindestens einen Thread. Wenn ein Prozess mehr als einen Thread startet, verteilt Windows diese normalerweise auf die verfügbaren Kerne.

Falls die Anwendung nunr schlecht programmiert ist, z.b. wenn ein Thread auf dem anderen warten muß oder die Anwendung ständig neue Threads aufmacht, könnte es u.U. zu einen solchen Verhalten kommen.

 

Wenn Du etwas mehr über Prozesse und Threads wissen willst, beschäftige Dich mal ein wenig mit Process Explorer . Mark hier auch div interessante Beiträge veröffentlicht:

 

Learn Sysinternals

 

-Zahni

[DeathAndPain2 10]

Iwe kommst Du darauf, dass Windows Prozesse von einem Kern zum Anderem schiebt ? Windows hat sicher was besseres zu tun.

Sollte man denken. Aber wie gesagt, zumindest für Vista ist dieses Verhalten sogar dokumentiert und hat wie oben erläutert dazu geführt, dass das innovative Pro-Kern-Power Management des Phenom I im Phenom II nicht mehr implementiert worden ist.

 

Eine gute Beispielapplikation ist das Spiel Age Of Mythology, bezeichnenderweise ein Microsoft-Spiel (wenn auch von deren Unterfirma Ensemble Studios programmiert). Dieses Spiel hält auf einem Einkernsystem den Prozessor stets auf 100% Last, egal wieviel oder wie wenig es macht. Anscheinend hat man es versäumt, sleep-Befehle zu nutzen und wartet stattdessen händisch in Warteschleifen auf die Echtzeituhr.

 

Wenn man dieses Programm jetzt auf einem Zweikernsystem ausführt, so beträgt die gesamte CPU-Belastung laut Task Manager 50%. Auf meinem Dreikernsystem sind es - oh Wunder - genau 33%! Die Kurven im Task Manager spiegeln dabei eine gleichmäßige Auslastung aller drei Kerne vor, aber an diesem Systemverhalten ist ganz klar ablesbar, daß hier immer nur einer der Kerne belastet ist, der aber mit 100%. Dementsprechend wild verhält sich das Cool'n'Quiet-Powermanagement hinsichtlich der Kernfrequenzen.

 

Insofern darfst Du nicht davon ausgehen, dass nicht sein kann, was nicht sein darf: Windows macht diesen Unsinn tatsächlich!

[LukasB 10]

Das Problem wurde in Windows 7 bzw. WS08R2 behoben.

 

Ask the Performance Team : Windows 7 / Windows Server 2008 R2: Core Parking / Intelligent Timer Tick / Timer Coalescing

 

virtualboy : Seeing Core Parking in action

[DeathAndPain2 10]

Ich fürchte, da liegst Du falsch, und zwar aus zwei Gründen:

• Ich arbeite mit Windows 7 x64, und das Systemverhalten ist noch immer genau das von mir beschriebene.
   
  
• Das Core Parking, zu dem Du verlinkt hast, verstehe ich so, dass das System möglichst erst mal einzelne Cores auslastet, bevor es weitere in Betrieb nimmt. Wenn Du also z.B. drei Kerne hast ein paar Anwendungen mit geringer Prozessorauslastung laufen, dann hättest Du im klassischen Fall auf jedem der drei Kerne - sagen wir 5% - Auslastung. Das würde aber insbesondere bedeuten, dass keiner der Kerne wirklich idle ist und steht damit dem dauerhaften Kernstillstand im Weg. Besser ist es, in diesem Fall alle Anwendungen auf denselben Kern zu packen. Dann läuft der mit 15% Auslastung - worüber er immer noch nur lachen kann - und die anderen Kerne gehen komplett schlafen. Dies ist offensichtlich effizienter als alle drei Kerne ein bißchen zu beschäftigen.
   
  Das ist das, was ich aus der von Dir verlinkten englischsprachigen Beschreibung herauslese, und es ist ja auch durchaus überzeugend. Ein Intel-Prozessor mit PowerGate-Technologie kann auf diese Weise sein PowerGate nutzen, um einige Kerne vollständig abzuschalten.
   
  Der von mir beschriebene Fall ist jedoch anders gelagert. Hier geht nämlich ein Kern auf 100%, und da sagt Windows: "Um Himmels willen, der eine Kern schafft es nicht mehr, während der nächste völlig lastfrei ist. Da schiebe ich doch mal Last auf den nächsten Kern, um den vorigen zu entlasten!" Leider erweist sich diese Maßnahme jedoch aus den zuvor geschilderten Gründen als völlig daneben. Und das ist auch in Windows 7 nicht anders.

[LukasB 10]

Windows 7: Microsoft Listens To Intel, Finally - Review Tom's Hardware : Intel Core i5 And Core i7: Intel?s Mainstream Magnum Opus

 

Die Anzeigen des Taskmanagers solltest du nicht überbewerten. Diese sind lediglich eine graphische Annäherung an das was effektiv passiert.

 

This changes with Windows 7 and a feature called ideal core. If a task’s needs are being addressed by one core, the operating system will let you stay there. This means two things to Intel: first, you don’t use power on the migration, and second, idle cores are able to remain in a C6 state.

[DeathAndPain2 10]

Windows 7: Microsoft Listens To Intel, Finally - Review Tom's Hardware : Intel Core i5 And Core i7: Intel?s Mainstream Magnum Opus

Dieser Artikel bestätigt doch genau das, was ich sage:

 

Core parking is a second optimization...The idea is to load all of those tasks onto one core and let the others idle if operating load levels allow for it.

 

Das entspricht doch akkurat meinem Beispiel mit den 3x 5% Last!

 

Die "erste" Optimierung, von der in dem Artikel die Rede ist, ist beschrieben durch:

 

If a task’s needs are being addressed by one core, the operating system will let you stay there.

 

Und genau hier ist der Pferdefuß. Applikationen wie Age of Mythology lasten ihren Kern immer zu 100% aus, unabhängig davon, wie leistungsfähig dieser Kern ist. Bezogen auf obiges Zitat aus dem Artikel heißt das: The need of the "Age of Mythology"-Task can never be addressed by any core! Windows stellt fest, dass die Leistung des Kerns nicht ausreicht, um den Taks zufriedenzustellen. (Vermutlich wird dies daran festgemacht, dass der Task den Kern auf 100% zieht, aber vielleicht greift hier auch ein anderer Algorithmus, der allerdings zu demselben Resultat gelangt.) Also wendet Windows die Optimierung nicht an und läßt den Task weiter von Kern zu Kern sausen.

 

Die Anzeigen des Taskmanagers solltest du nicht überbewerten. Diese sind lediglich eine graphische Annäherung an das was effektiv passiert.

Aber in diesem Fall doch eine recht eindeutige. Wenn ich die Affinität des Prozesses auf einen Kern beschränke, dann geht der auf 100% und die anderen auf 0% (Das wäre der wünschenswerte Zustand.) Defaultmäßig aber zittern alle drei Kerne bei mäßiger Auslastung. Die Gesamtauslastung des ganzen Prozessors (d.h. aller Kerne zusammen) beziffert der Task Manager in beiden Fällen mit exakt 33%. Diese Zahl nennt der Task Manager ganz explizit; die lese ich nicht nur aus dem Graphen ab. Das ist ein ganz eindeutiger Befund, der mit Ungenauigkeiten auf Seiten des Task Managers nicht ins Wanken zu bringen ist.

 

Im übrigen zeigt der AMD Power Monitor, der die Cool'n'Quiet-Effekte des Prozessors für jeden einzelnen Kern sichtbar macht, genau das gleiche Bild. Windows kann anscheinend nicht sinnvoll mit Tasks umgehen die einen Kern zu 100% und mehr fordern. Jedenfalls nicht "sinnvoll" im Sinne des Powermanagement, denn Windows versucht in diesem Falle zu parallelisieren, wo es nichts zu parallelisieren gibt.

[zahni 524]

Dir ist aber bewusst, dass Pozesse in Threads abufgeteilt sind, das habe ich Dir ja schon geschrieben.

 

Wenn nun es 3D-Spiel gespielt wird, warum glaubtst Du dass da nur der Prozess (der Topf mit den Threads) die CPU-Last macht ? Es muss Disk I/O gemacht werden, der Treiber von GK hat zu tun, usw.

 

Nochmals mein Tip: Schaue Dir den ProcessMonitor an. Da kannst DU bis in die Tiefe schauen, welcher Thread welche Auslastung verursacht.

 

Eventuell reicht auch schon der ResourcenMonitor.

 

das Zitat

 

The affinity of a thread will always be honored. If a thread is affinitized to parked cores only, it will be scheduled to one of the parked cores. On a client machine, most threads do not explicitly set an affinity and therefore run with an affinity including all processors in the system, allowing for frequent use of core parking. On servers where applications are more often finely tuned, threads may be affinitized to specific processors, which can reduce the effectiveness of core parking.

 

Additionally, on NUMA systems, the scheduler is free to override the core parking mask and schedule a thread to a parked core in its ideal node. This reduces the performance impact of forcibly migrating threads away from its ideal node. If all processors in a node are parked and there are no available un-parked cores, the scheduler is free to run the thread on a parked core within the same node. Nehalem processors allow for entire processor sockets to be parked, whereas most pre-Nehalem processors only allow individual cores to be parked. The state of individual parked cores can be observed in Resource Monitor when the CPU tab is selected …

 

Sagt doch alles, oder ? Hast Du ein NUMA-System ? Das geht nur mit den ganz aktuellen Intel-Dingern oder den AMD Opterons.

 

Quad-Cores in Desktop-PC's sind eh sinnfrei.

 

-Zahni

[DeathAndPain2 10]

Dir ist aber bewusst, dass Pozesse in Threads abufgeteilt sind, das habe ich Dir ja schon geschrieben.

 

Wenn nun es 3D-Spiel gespielt wird, warum glaubtst Du dass da nur der Prozess (der Topf mit den Threads) die CPU-Last macht ?

Das kommt auf das Spiel an. Du redest von Parallelisierung, ich davon, dass es immer davon abhängt, wie gut die jeweilige Applikation parallelisierbar ist. Das Beispiel Age of Mythology ist offensichtlich so gut wie gar nicht parallelisierbar, so dass neben dem einen Kern, den es über das Hauptprogramm auf 100% zieht, die beiden anderen mit unter einem Prozent ausgelastet werden (bei einem Dreikernsystem). Richtig moderne Spiele nutzen CUDA bzw. DirectX11 und lassen die 3D-Berechnungen von der Grafikkarte machen, so dass auch hierdurch keine CPU-Last mehr anfällt.)

 

Wenn Du ein gut geschriebenes Programm hast, das sich gleichmäßig in viele parallelisierbare Threads auffächert, dann sieht das natürlich anders aus. Um solche Software geht es hier in diesem Thread aber nicht. Zudem gibst Du doch in Deinem letzten Satz selber zu, dass auf üblichen Desktop-Systemen normalerweise keine Software läuft, die sich gut parallelisieren läßt. (Auch wenn ich Dir nicht bis zu dem Begriff "sinnfrei" folgen möchte. Neue Software wird nämlich sehr wohl auch mit Parallelisierbarkeit im Hinterkopf programmiert und kompiliert. So kann z.B. bei einem Spiel ein Kern die Soundberechnung machen, ein weiterer das Hauptprogramm, ein dritter die AI, die dann dem Hauptprogramm Befehle übergibt, als ob sie ein menschlicher Spieler wäre. Einen vierten Kern kannst Du mit dem üblichen Virenscanner belasten. Also gehen tut es schon, und derartige Software wird auch geschrieben. Hier in diesem Thread geht es aber um ältere oder schlecht programmierte Software, die nur linear abgearbeitet werden kann und keine Nebenthreads mit nennenswerter (!) CPU-Auslastung benötigt.)

[LukasB 10]

Das kommt auf das Spiel an. Du redest von Parallelisierung, ich davon, dass es immer davon abhängt, wie gut die jeweilige Applikation parallelisierbar ist. Das Beispiel Age of Mythology ist offensichtlich so gut wie gar nicht parallelisierbar, so dass neben dem einen Kern, den es über das Hauptprogramm auf 100% zieht, die beiden anderen mit unter einem Prozent ausgelastet werden (bei einem Dreikernsystem).

 

CPU-Affinity wird im Taskmanager auf Prozess- und nicht auf Thread-Ebene vergeben. Wenn du also einem blah.exe eine Affinity auf Core 1 gibst, und blah.exe aus 5 Threads besteht, laufen nachher alle 5 Threads auf Core 1.

[zahni 524]

3D Berechnungnen werden eben nicht komplett von der Hardware der GK gemacht. Das wird zwar immer besser, hängt aber auch vom Spiel ab. Im speziellen Fall wird das Spiel einfach 3 Threads benutzen, die Windows dann auf die Cores verteilt. Warum nun nicht mit 100% laufen, wird daran liegen, wie das Programm geschrieben ist. Ein Programm kann durchaus mit mehr als einem Thread arbeiten, aber nicth darauf optimiert sein, dass die Threads auf mehr als einer CPU laufen. Wenn man es nun auf einem Mehrkern-System startet, erteilt Windows die Threads. Was sollte es da erkennen ?

 

Wenn Du nun die CPU-Affinity setzt, "weiss" Windows, dass es alle Threads auf dem selben Core laufen lassen soll. Per default, wird sowas bei der Programmentwicklung im EXE-Header festgelegt.

 

Siehe auf mal als Hintergrund:

IBM - Setting processor affinity for threads or services

 

Wie gesagt, es gibt Porgramme, die von Design her nicht gut auf Multicore reagieren. Drumm auch mein Tip mit dem Process Explorer. Dort kannst Du Dir Details zu den hreads anzeigen lassen.

 

Windows ist nicht gegen schlecht programmierte Soffware geschützt ;)

 

PS: Für den normalen Destop-PC reichen 2 Kerne: 1x für den Virenscanner und 1x für den Rest. Wer spielen will, sollte sich die Spiele genau ansehen.

Da ist fetter Core2 mit höherer Frequenz meist auch besser als ein langsamerer Quadcore

 

-Zahni

[DeathAndPain2 10]

Das beweist erst recht meine Ausführungen. Wenn ohne eingeschränkte Affinität die anderen Kerne irgendwie sinnvoll mitmachen und die Abarbeitung von Unterthreads übernehmen würden, dann müßte die Gesamtprozessorlast größer als 33% sein (100% auf dem Kern mit dem Hauptprogramm, weil das immer 100% zieht, und halt ein bißchen was auf den anderen Kernen). Bei eingeschränkter Affinität wäre es dann 33% Gesamtprozessorlast, weil dann nur ein Kern ausgelastet ist und die anderen in Ruhe gelassen werden.

 

Da es aber in der Realität in beiden Fällen 33% Gesamtprozessorlast sind, kann man sehr schön erkennen, dass hier gar nichts parallel läuft - obwohl alle drei Kerne durchschnittlich gleich viel beschäftigt werden und die Taktfrequenzen der Einzelkerne per Cool'n'Quiet Karussell fahren (im Mikrosekundenrhythmus hoch und runter, wie auch der AMD Power Monitor verrät). Das kann doch nicht effizient sein?!

[zahni 524]

Du hast ja sowas von recht.

 

Doch sieh doch endlich mal ein, das nicht Windows schuld ist, sondern die Anwendung. Multithreading macht nur Sinn, wenn wirklich Threads parallel laufen können. Wenn sie aufeinander warten, macht es nur bedingt Sinn. Der Kernel ist aber kaum in der Lage sowas zu erkennen.

 

-Zahni