Wie interagiert die CPU-Affinität mit cgroups unter Linux?

Ich versuche, Multithread-Benchmarks auf einer Reihe isolierter CPUs auszuführen. Um es kurz zu machen, ich habe es zunächst mit isolcpusund versucht, bin tasksetaber auf Probleme gestoßen . Jetzt spiele ich mit cgroups / csets.

Ich denke, der "einfache" cset shieldAnwendungsfall sollte gut funktionieren. Ich habe 4 Kerne, daher möchte ich die Kerne 1-3 für das Benchmarking verwenden (ich habe diese Kerne auch so konfiguriert, dass sie sich im adaptiven Ticks-Modus befinden), dann kann Kern 0 für alles andere verwendet werden.

Nach dem Tutorial hier sollte es so einfach sein wie:

$ sudo cset shield -c 1-3
cset: --> shielding modified with:
cset: "system" cpuset of CPUSPEC(0) with 105 tasks running
cset: "user" cpuset of CPUSPEC(1-3) with 0 tasks running

Jetzt haben wir also ein "Schild", das isoliert ist (das Benutzer-Cset) und Kern 0 ist für alles andere (das System-Cset).

Okay, sieht soweit gut aus. Nun schauen wir uns an htop. Die Prozesse sollten alle auf CPU 0 migriert worden sein:

Huh? Einige der Prozesse laufen auf den abgeschirmten Kernen. Um den Fall auszuschließen, dass htop einen Fehler aufweist, habe ich auch versucht taskset, die Affinitätsmaske eines Prozesses zu untersuchen, der sich im Schild befindet.

Vielleicht waren diese Aufgaben unbeweglich? Lassen Sie uns einen beliebigen Prozess zupfen, der auf CPU3 ausgeführt wird (der sich im Schild befinden sollte), htopund prüfen, ob er in der System-C-Gruppe wie folgt angezeigt wird cset:

$ cset shield -u -v | grep 864
   root       864     1 Soth [gmain]
   vext01    2412  2274 Soth grep 864 

Ja, das läuft auf der Systemgruppe nach cset. Also htopund nicht cseteinverstanden.

Also, was ist hier los? Wem vertraue ich: CPU-Affinitäten ( htop/ taskset) oder cset?

Ich vermute, dass Sie nicht csetund Affinitäten zusammen verwenden sollen. Vielleicht funktioniert der Schild gut, und ich sollte die Affinitätsmasken und die htopAusgabe ignorieren . In jedem Fall finde ich das verwirrend. Kann jemand etwas Licht ins Dunkel bringen?

Aus der cpusets-Dokumentation :

Aufrufe von sched_setaffinity werden nur auf die CPUs gefiltert, die im cpuset dieser Task zulässig sind.

Dies impliziert, dass CPU-Affinitätsmasken mit dem CPU in der Gruppengruppe, zu der der Prozess gehört, geschnitten werden.

Wenn beispielsweise die Affinitätsmaske eines Prozesses die Kerne {0, 1, 3} enthält und der Prozess auf der System-cgroup ausgeführt wird, die auf die Kerne {1, 2} beschränkt ist, muss der Prozess auf Kern 1 ausgeführt werden.

Ich bin zu 99% sicher, dass die htopAusgabe "falsch" ist, da die Prozesse seit der Erstellung der cgroups nicht mehr aktiviert wurden und auf dem Display der letzte Kern angezeigt wird, auf dem der Prozess ausgeführt wurde.

Wenn ich vim starte, bevor ich meinen Schild mache, gabelt sich vim zweimal (aus irgendeinem Grund) und das tiefste Kind läuft auf Kern 2. Wenn ich dann den Schild mache, dann schlafe vim (Strg + z) und wecke ihn, beide Prozesse haben Ich denke, dies bestätigt die Hypothese, htopdass veraltete Informationen angezeigt werden.

Sie können auch /proc/<pid>/statusdie cpus_allowed_*Felder inspizieren und betrachten .

ZB habe ich hier einen console-kit-daemonProzess (pid 857), der in htop als auf Kern 3 laufend angezeigt wird, aber in /proc/857/status:

Cpus_allowed:   1
Cpus_allowed_list:      0

Ich denke, dies bedeutet, dass die Affinitätsmaske 0x1 ist, was aufgrund der cgroups erlaubt, nur auf Kern 1 zu laufen: dh intersect ({0,1,2,3}, {0}) = {0}.

Wenn ich kann, lasse ich die Frage eine Weile offen, um zu sehen, ob eine bessere Antwort kommt.

Vielen Dank an @davmac für die Hilfe (auf irc).