Wie funktioniert sched_setaffinity()?

Question

Ich versuche zu verstehen, wie der Linux syscall sched_setaffinity() funktioniert. Dies ist eine Folge meiner Frage here.

Ich habe this guide, die erklärt, wie man den syscall benutzt und hat ein hübsches ordentliches (Arbeiten!) Beispiel.

Also habe ich das Linux 2.6.27.19 kernel sources heruntergeladen.

Ich habe eine 'grep' für Zeilen mit diesem syscall, und ich habe 91 Ergebnisse. Nicht vielversprechend.

Letztlich, ich versuche zu verstehen, wie der Kernel in der Lage ist, den Befehlszeiger für einen bestimmten Kern einzustellen (oder Prozessor.)

Ich bin vertraut mit, wie Single-Core-Single-Thread-Programme Arbeit. Man könnte eine 'jmp foo'-Anweisung ausgeben, und dies setzt die IP im Grunde auf die Speicheradresse der' foo'-Marke. Aber wenn man mehrere Kerne hat, muss man sagen "hole den nächsten Befehl an die Speicheradresse foo und setze den Befehlszeiger für Kernnummer 2, um die Ausführung dort zu beginnen."

Wo geben wir im Assembly-Code an, welcher Kern diese Operation ausführt?

Zurück zum Kernel-Code: Was ist hier wichtig? Die Datei 'kernel/sched.c' hat eine Funktion namens sched_setaffinity(), gibt aber den Typ "long" zurück - was mit manual page nicht übereinstimmt. Was ist hier wichtig? Welches dieser Module zeigt die ausgegebenen Montageanweisungen? Welches Modul liest das 'task_struct', schaut sich das Mitglied 'cpus_allowed' an und übersetzt es dann in eine Anweisung? (Ich habe auch die glibc-Quelle durchsucht - aber ich denke, sie ruft einfach den Kernel-Code an, um diese Aufgabe zu erledigen.)

Answer 1

teilt einfach dem Scheduler mit, auf welche CPUs dieser Prozess/Thread ausgeführt werden darf, fordert dann einen erneuten Zeitplan.

Der Scheduler läuft tatsächlich auf jeder der CPUs, so dass er entscheiden kann, welche Aufgabe als nächstes auf dieser bestimmten CPU ausgeführt werden soll.

Wenn Sie daran interessiert sind, wie Sie tatsächlich etwas Code auf anderen CPUs aufrufen können, schlage ich vor, Sie sehen smp_call_function_single(). Falls wir etwas auf einer anderen CPU aufrufen wollen, ruft dies generic_exec_single() auf. Letzteres fügt einfach die Funktion der Anrufwarteschlange der Ziel-CPU hinzu und erzwingt eine Neuplanung durch etwas IPI Zeug (wenn die Warteschlange leer war).

Fazit: Es gibt keine tatsächliche SMP-Variante der _jmp_ Anweisung. Stattdessen arbeitet Code, der auf anderen CPUs ausgeführt wird, zusammen, um die Aufgabe zu erfüllen.

Answer 2

Wo geben wir im Assembly-Code an, welcher Kern diese Operation ausführt?

Hier ist keine Baugruppe beteiligt. Jeder Task (Thread) ist jeweils einer einzelnen CPU (oder einem Kern in Ihren Bedingungen) zugewiesen. Um auf einer bestimmten CPU zu stoppen und auf einer anderen fortzusetzen, muss die Task "migrate" (auch this) lauten. Wenn eine Task von einer CPU zu einer anderen migriert, verwendet der Scheduler picks die CPU, die unter den von zugelassenen CPUs mehr Leerlauf hat.

Es wurden keine magischen Montageanweisungen ausgegeben.Der Kernel hat eine tiefere Ansicht der Hardware, jede CPU ist ein separates Objekt, ganz anders als es für User-Space-Prozesse aussieht (im User-Space sind CPUs fast unsichtbar).

Answer 3

Ich denke, die Sache, die Sie nicht verstehen, ist, dass der Kernel auf die CPU-Kerne läuft. Bei jedem Timer-Interrupt (~ 1000 pro Sekunde) wird der Scheduler auf jeder CPU ausgeführt und wählt einen auszuführenden Prozess aus. Es gibt keine CPU, die die anderen irgendwie anweist, einen Prozess zu starten. funktioniert nur durch Setzen von Flags auf den Prozess. Der Scheduler liest diese Flags und führt diesen Prozess nicht auf seiner CPU aus, wenn er nicht gesetzt ist.

Answer 4

Check this out: B Operating System Programming Guidelines