Gewünschtes Verhalten: Führen Sie ein Multithread-Linux-Programm auf einer Reihe von Kernen aus, die mit isolcpus isoliert wurden.
Hier ist ein kleines Programm, das wir als Beispiel für ein Multi-Thread-Programm verwenden können:
%Vor%Wenn ich das auf einem Kernel ohne isolierte CPUs kompiliere und ausführe, dann verteilen sich die Threads über meine 4 CPUs. Gut!
Wenn ich nun isolcpus=2,3 zur Befehlszeile des Kernels hinzufüge und neu starte:
taskset -c 0,1 hat denselben Effekt. Gut. taskset -c 2,3 werden alle Threads auf denselben Core (Core 2 oder Core 3) verschoben. Dies ist unerwünscht. Threads sollten sich über die Kerne 2 und 3 verteilen. Richtig? Dieser Beitrag beschreibt eine ähnliche Problem (obwohl das angegebene Beispiel weiter von der Pthreads-API entfernt ist). Das OP war froh, dies mit einem anderen Scheduler umgehen zu können. Ich bin mir aber nicht sicher, ob dies für meinen Anwendungsfall ideal ist.
Gibt es eine Möglichkeit, die Threads mithilfe des Standard-Schedulers über die isolierten Kerne zu verteilen?
Ist das ein Kernel-Bug, den ich melden sollte?
BEARBEITEN :
Das Richtige passiert tatsächlich, wenn Sie einen Echtzeit-Scheduler wie den Fifo-Scheduler verwenden. Siehe man sched und man chrt für Details.
Aus dem Linux Kernel Parameter Doc:
Diese Option kann verwendet werden, um eine oder mehrere zu isolierende CPUs anzugeben die allgemeinen SMP-Balancing- und Scheduling-Algorithmen.
Diese Optionen würden also effektiv verhindern, dass der Scheduler die Threadmigration von einem Kern zu einem anderen weniger umkämpften Kern (SMP-Balancing) durchführt. Als typische Isolcpus werden zusammen mit Pthread-Affinitätskontrolle verwendet, um Threads mit Kenntnis des CPU-Layouts zu pinnen, um eine vorhersehbare Leistung zu erzielen.
- Bearbeiten -
Ok, ich verstehe, warum du verwirrt bist. Ja persönlich würde ich konsequentes Verhalten bei dieser Option annehmen. Das Problem liegt bei den zwei Funktionen select_task_rq_fair und select_task_rq_rt, die für die Auswahl der neuen run_queue verantwortlich sind (die im Wesentlichen auswählen, welches next_cpu ausgeführt werden soll). Ich machte eine schnelle Ablaufverfolgung (Systemtap) beider Funktionen, für CFS würde es immer denselben ersten Kern in der Maske zurückgeben; Für RT würde es andere Kerne zurückgeben. Ich habe keine Chance, die Logik in jedem Auswahlalgorithmus zu untersuchen, aber Sie können eine E-Mail an den Betreuer in der Linux-Entwickler-Mailingliste für die Fehlerbehebung senden.
Tags und Links multithreading linux scheduler affinity