[erledigt: Ist Bug im Systemmonitor] Linux: CPUs abschalten funktioniert nicht wie erwartet

SeppJ

Hat sich von selbst erledigt. Siehe edit3.

Hallo,

bei meinem Hyperthreadingsystem hätte ich gerne eine Möglichkeit, im Betrieb das Hyperthreading zu deaktivieren. Denn HT ist manchmal doof: Es funkt bei Benchmarks dazwischen und macht die Prioritäten des Schedulers kaputt. Sprich: CPU-hungrige Vordergrundjobs bekommen effektiv nur einen halben Kern, was manchmal nicht gewünscht ist.

Bei meinem alten System (irgendein i7 mit 8 virtuellen Kernen) habe ich dazu die Kerne 4-7 deaktiviert, indem ich eine 0 in die entsprechenden Dateien geschrieben habe:

/sys/devices/system/cpu/cpuX/online

Doch anscheinend hatte ich dabei entweder nur Glück oder das Verhalten hat sich geändert. Denn mein neues System (2x irgendein Xeon-E mit insgesamt 24 virtuellen Kernen) hat die virtuellen Kerne auf den Nummern 1,3,5,7, usw. Sehen kann man das an der core id in /proc/cpuinfo (so wusste ich auch, welches die virtuellen Kerne beim i7 waren)^*.

Doch nun das Unerwartete: Wenn ich eine 0 in eine der Gerätedateien schreibe, deaktiviert der Scheduler alle CPUs ab dieser Stelle! Wenn ich beispielsweise CPU5 auf 0 setze, dann werden 5-23 deaktiviert. Ist dieses Verhalten korrekt? Wie kann ich mein Ziel trotzdem erreichen? (Lösungen mit Neustart kommen nicht in Frage. Und bitte auch keine extrem umständlichen Lösungen, wie "nur die letzte CPU deaktivieren und den Vordergrundjob an die vorletzte CPU binden".)

edit: Wichtige Info: Wie stelle ich dieses Verhalten fest? An der CPU-Auslastung im xfce-Systemmonitor. Könnte natürlich auch ein Fehler in diesem Tool sein. Und die Performance des Vordergrundjobs scheint immer noch gering. Wenn ich aber /proc/interrupts betrachte, dann sind tatsächlich nur die deaktivierten CPUs offline . Ich mache mal genaue Benchmarks.

edit2: Genauere Messungen haben ergeben, dass der Scheduler selbst doch wie erwartet funktioniert und der Bug wohl im Systemmonitor ist. Und ich habe die core ids falsch gelesen, die virtuellen Kerne sind 6-11 und 18-23 . Trotzdem bleibt die Performance der Vordergrundanwendungen gering. Am performantesten war es, als ich die 2. physische CPU (CPUs 12-23) abgeschaltet habe. Also immer noch nicht so ganz gelöst.

edit3: [erledigt]. Ich bin ja so ein Schussel. Die virtuellen Cores waren 12-23. Zu viele Seiten in /proc/cpuinfo. Wer kann schon 24 Wertetripel gleichzeitig im Kopf verarbeiten ? Zu viele Kombinationen von CPI id, Core id und physical id. Wenn man diese Kerne abschaltet, dann klappt's auch mit der Vordergrundperformance. Der Bug im Systemmonitor bleibt bestehen, da habe ich einen entsprechenden Report eingereicht.

^*: Es ist natürlich Willkür, die virtuellen Kerne als 1,3,5,7,... zu bezeichnen, ich könnte auch genau so gut 0,2,4,6,... nehmen. Hauptsache nur eine CPU pro core id.

hustbaer

SeppJ schrieb:

Hallo,

bei meinem Hyperthreadingsystem hätte ich gerne eine Möglichkeit, im Betrieb das Hyperthreading zu deaktivieren. Denn HT ist manchmal doof: Es funkt bei Benchmarks dazwischen und macht die Prioritäten des Schedulers kaputt. Sprich: CPU-hungrige Vordergrundjobs bekommen effektiv nur einen halben Kern, was manchmal nicht gewünscht ist.

Was genau meinst du?

A: Es sind maximal N/2 Threads aktiv, der Scheduler verteilt die aber dummerweise einfach irgendwie auf die virtuellen Cores, und daher landen trotzdem manchmal zwei aktive Threads auf dem selben physikalischen Core.
oder
B: Es sind manchmal mehr als N/2 Threads aktiv, von denen ein paar aber nicht so wichtig sind, und du hättest gern dass die wichtigen eben alleine auf einem physikalischen Core laufen, auch wenn ein paar weniger wichtige dann gar keine Rechenzeit bekommen.

Falls es um B geht musst du wohl oder übel HT deaktivieren - die Scheduler sind normalerweise auf maximalen Gesamt-Throughput und nicht auf minimale Latenz optimiert.
Falls es um A geht, dann wundert mich allerdings dass der Scheduler das nicht selbst im Griff hat. Windows *sollte* das können, zumindest hat es da bei Windows XP oder Vista extra mal ne Kernel-Anpassung für HT gegeben. Und angenommen meine Informationen diesbezüglich sind nicht falsch, dann wäre es mir ein Fest mich wiedermal zerkringeln zu können wenn Linux das nicht kann

SeppJ

Es geht um B.

Das Abschalten der entsprechenden Cores entspricht dann ja dem Abschalten von HT. Technisch gesehen mag die CPU zwar noch im HT-Modus sein, aber der Scheduler legt dann nichts mehr auf den virtuellen Kern. Das ist ausreichend für mich und funktioniert auch (zumindest, wenn ich es denn korrekt mache )

A kann Linux natürlich auch korrekt.

hustbaer

Schade

Und ja, klar, ich meinte eh HT abschalten oder halt so wie du es gemacht hast. Und dass dir der Scheduler das halt nicht abnehmen kann. (Also er könnte natürlich, aber da für die meisten Anwendungsfälle das andere Verhalten besser ist, tut er es nicht.)

SeppJ

P.S.: CPUs mitten im Betrieb abschalten; potentiell Hardware einbauen, ausbauen oder ersetzen; dann CPU wieder hochfahren: Das kann Windows aber nicht, oder?

volkard

SeppJ schrieb:

P.S.: CPUs mitten im Betrieb abschalten; potentiell Hardware einbauen, ausbauen oder ersetzen; dann CPU wieder hochfahren: Das kann Windows aber nicht, oder?

Wer sagt, daß dieses "abschalten" der CPU alle Leitungen vom Board hochohmig macht, so daß man die CPU ziehen könnte?

SeppJ

volkard schrieb:

SeppJ schrieb:

P.S.: CPUs mitten im Betrieb abschalten; potentiell Hardware einbauen, ausbauen oder ersetzen; dann CPU wieder hochfahren: Das kann Windows aber nicht, oder?

Wer sagt, daß dieses "abschalten" der CPU alle Leitungen vom Board hochohmig macht, so daß man die CPU ziehen könnte?

Das Kernelhandbuch . Ok, man muss beim Compilieren des Kernels noch ein bestimmtes Flag setzen, das bei meiner Standard-Desktop-Distribution wahrscheinlich nicht gesetzt ist, aber an sich geht das (Die Hardware muss das natürlich auch anbieten, was wahrscheinlich nur bei guten Serverboards der Fall ist).

oenone

SeppJ schrieb:

P.S.: CPUs mitten im Betrieb abschalten; potentiell Hardware einbauen, ausbauen oder ersetzen; dann CPU wieder hochfahren: Das kann Windows aber nicht, oder?

Doch, Windows Server kann das auch. Genauso wie Linux. Voraussetzung ist auf jeden Fall, dass die Hardware (das Mainboard) und das BIOS dies auch unterstützen.

Siehe auch:
Hinzufügen von CPUs im laufenden Systembetrieb