Prozess auf einen bestimmten Prozessor/Kern festlegen
-
Ist es möglich vor dem Starten eines Prozesses (also vor fork ()) irgendwie festzulegen, auf welchem Prozessor bzw. Prozessorkern der Prozess laufen soll? Könnte man auch festlegen, auf welchen Prozessoren/Kernen Threads dieses Prozesses laufen dürfen?
-
Geht mit irgendeinem hässlichen Hack bestimmt.
Aber wozu sollte man das machen wollen?
-
Naja, wenn ich mein Programm so auslege, dass es mit mehreren Prozessen läuft (um halt die Multikernprozessoren oder Systeme mit mehreren Prozessoren nutzen zu können), sollten die Prozesse tunlichst auf alle verfügbaren Prozessoren/Kerne verteilt werden. Bei einem normalen fork () ist es doch, wenn die Prozessoren bisher nicht großartig ausgelastet sind, weitgehend "zufällig", auf welchem Prozessor/Kern der Prozess nun landet. Aber mehrere Prozesse auf dem selben Prozessor/Kern bringen mir ja nicht viel.
-
Siehe sched_setaffinity
-
devkid schrieb:
Naja, wenn ich mein Programm so auslege, dass es mit mehreren Prozessen läuft (um halt die Multikernprozessoren oder Systeme mit mehreren Prozessoren nutzen zu können), sollten die Prozesse tunlichst auf alle verfügbaren Prozessoren/Kerne verteilt werden.
Das macht Dein Scheduler für Dich, ich habe bis jetzt kaum einen sinnvollen Anwendungsfall dafür gesehen, das selbst in die Hand nehmen zu wollen.
Ponto: Sollte ich wohl mal bookmarken. Aber irgendwie finde ich diese ganzen rein linuxspezifischen Funktionen nicht so interessant.
-
@Ponto: Thx, das hab ich gesucht.
Und nach soo nem bösen Hack sieht das auch wieder nicht aus. :p@nman: Mit sched_getaffinity kann ich wenigstens beobachten, ob die Prozesse auf den richtigen Prozessoren landen. Wenn auch so glatt läuft, brauch ichs halt nicht. Aber es ist immer nett zu wissen, dass es solche Funktionen gibt.
-
devkid schrieb:
Und nach soo nem bösen Hack sieht das auch wieder nicht aus. :p
Das Ding ist Linux-only und sagt dem Scheduler, dass er etwas machen soll, wovon er ziemlich sicher besser weiß, was gut ist, als Du es tust. Ich halte das für böse genug, besonders wenn man sich das Kosten-/Nutzenverhältnis vor Augen führt.
Mit sched_getaffinity kann ich wenigstens beobachten, ob die Prozesse auf den richtigen Prozessoren landen.
Eigentlich kannst Du Dir damit nur die Affinitätsmaske holen. Zum Prozesse überwachen kannst Du auch auf simplere Lösungen zurückgreifen.
-
nman schrieb:
devkid schrieb:
Und nach soo nem bösen Hack sieht das auch wieder nicht aus. :p
Das Ding ist Linux-only und sagt dem Scheduler, dass er etwas machen soll, wovon er ziemlich sicher besser weiß, was gut ist, als Du es tust. Ich halte das für böse genug, besonders wenn man sich das Kosten-/Nutzenverhältnis vor Augen führt.
Hm vielleicht denk ich auch grad total falsch, aber bleibt ein Prozess nicht auf einen Prozessor beschränkt, wenn er diesem mal zugeteilt wurde?
Oder weist der Scheduler bei jedem Interrupt andere Prozessoren zu?nman schrieb:
Mit sched_getaffinity kann ich wenigstens beobachten, ob die Prozesse auf den richtigen Prozessoren landen.
Eigentlich kannst Du Dir damit nur die Affinitätsmaske holen. Zum Prozesse überwachen kannst Du auch auf simplere Lösungen zurückgreifen.
Stimmt wohl, da sieht man ja nur, auf welchen Prozessoren er laufen darf.
-
nman schrieb:
devkid schrieb:
Naja, wenn ich mein Programm so auslege, dass es mit mehreren Prozessen läuft (um halt die Multikernprozessoren oder Systeme mit mehreren Prozessoren nutzen zu können), sollten die Prozesse tunlichst auf alle verfügbaren Prozessoren/Kerne verteilt werden.
Das macht Dein Scheduler für Dich, ich habe bis jetzt kaum einen sinnvollen Anwendungsfall dafür gesehen, das selbst in die Hand nehmen zu wollen.
es stimmt zwar, dass es eine Arbeit des Schedulers sein sollte, aber es kommt durchaus vor. Hab sowas bei SAT-Solvern gesehen, da versucht man gerade mehrere SAT-Solver gleichzeitig laufen zu lassen und jeder auf einen einzelnen Kern. Ich weiß aber nicht, wie sowas geht (hab den Quellcode der SAT-Solver nicht) aber ich kenne Leute, die daran arbeiten.
-
devkid schrieb:
bleibt ein Prozess nicht auf einen Prozessor beschränkt, wenn er diesem mal zugeteilt wurde?
Nein, falls die Arbeitsaufteilung zwischen den beiden CPUs nicht passt, wird umverteilt, der Suchbegriff hierfür ist schlicht "load balancing". Gecheckt wird das immer wenn das System gerade Idle ist oder die Run-Queue einer CPU geleert wurde, zumindest aber alle 200ms. Wenn Du Code sehen willst, ist wohl
find_busiest_queuedie Funktion Deiner Wahl.supertux schrieb:
es stimmt zwar, dass es eine Arbeit des Schedulers sein sollte, aber es kommt durchaus vor. Hab sowas bei SAT-Solvern gesehen, da versucht man gerade mehrere SAT-Solver gleichzeitig laufen zu lassen und jeder auf einen einzelnen Kern. Ich weiß aber nicht, wie sowas geht (hab den Quellcode der SAT-Solver nicht) aber ich kenne Leute, die daran arbeiten.
Naja, ist eben eine Mikrooptimierung, die sich in einigen Randfällen minimal bemerkbar machen kann. Wenn Du von Haus aus weißt, dass Du alle Kerne voll ausnutzen wirst, kannst Du Dir eben ein paar cold caches ersparen, das gilt aber nur bis das System mal läuft, ist also eine meist eher vernachlässigbare Konstante.
sched_setaffinity sollte eher als Tip an den Scheduler gesehen und verwendet werden, denn als "Ich weiß besser als der Scheduler, wo mein Prozess laufen soll"-Funktion, damit schießt man sich nämlich ziemlich leicht in den Fuß. Und nicht vergessen: ifdefs verwenden, um die Programme auch unter anderen Unices lauffähig zu halten.
-
Hi,
Ich hab zwar keine Ahnung vom Thema, aber wird denn nicht wenn man ein neuer Thread erstellt dieser automatisch falls vorhanden auf die andere Kerne verteilt?MFG ReduX
-
ReduX schrieb:
Hi,
Ich hab zwar keine Ahnung vom Thema, aber wird denn nicht wenn man ein neuer Thread erstellt dieser automatisch falls vorhanden auf die andere Kerne verteilt?MFG ReduX
Ja, das wird er. Aber insgesamt hängt es von der Gesamtbelegung des Systems ab. Alle Threads in allen Prozessen konkurrieren um die CPUs. Der Scheduler weiss oft, aber nicht immer, was das Beste ist, um alle Threads zu verteilen.
-
Wäre es nicht sinnvoller in diesen Fällen einen anderen Scheduler zu benutzen? In den meisten Fällen wird es sich dabei eher weniger um ganz gewöhnliche PCs mit ganz gewöhnlicher Software handeln, oder nicht?