Verwenden von Linux-Gruppen, um die CPU-Leistung auszugleichen

Ich habe zwei Dual-Core-Linux-Systeme installiert, die Linux-Cgroups mit relativ neuen Kerneln verwenden. Auf dem einen läuft Debian Squeeze, auf dem anderen Ubuntu 11.04 Natty Narwhal. Ich habe einen CPU-Lastausgleich erhalten, bei dem cgroups auf dem Debian-System trotz des älteren Kernels etwas besser funktionieren. Aber es ist nicht für alles richtig, und die besondere Kuriosität, nach der ich hier frage, tritt auf beiden Systemen auf.

Wenn Sie Resource Management unter Linux mit Kontrollgruppen lesen, wird anhand eines Beispiels gezeigt, wie das Problem reproduziert werden kann. Hier ist die Ubuntu-Version (als root ausführen):

cd /sys/fs/cgroup/cpu
    [On Debian Squeeze start at /mnt/cgroups/cpu instead]
mkdir low high
echo 512 > low/cpu.shares
echo 2048 > high/cpu.shares
yes low > /dev/null &
echo $! > low/tasks
yes high > /dev/null &
echo $! > high/tasks
ps -C yes -opid,%cpu,psr,args
    [repeat that a few times]
killall -9 yes

Ich hatte damit gerechnet, dass dem "hohen" Prozess mehr Zeit eingeräumt wird als dem "niedrigen". Was mit diesem Testfall tatsächlich passiert, sieht immer so aus:

root@black:/sys/fs/cgroup/cpu# ps -C yes -opid,%cpu,psr,args
  PID %CPU PSR COMMAND
 3105 88.3   1 yes low
 3106 94.5   0 yes high

Wo die Zeiten fast gleich sind. Hier ist meine Frage: Warum passiert das?

In der Präsentation wird gezeigt, wie dieses Problem behoben wird, indem jeder Prozess an dieselbe CPU angeheftet wird. zusätzliche Zeilen, um das zu testen:

taskset -c 1 yes high > /dev/null &
echo $! > high/tasks
taskset -c 1 yes low > /dev/null &
echo $! > low/tasks
ps -C yes -opid,%cpu,psr,args
[later, rinse, repeat]
killall -9 yes

Das Ergebnis ist dann das, was ich erwartet hatte: der "hohe" Prozess bekommt einen viel höheren Prozentsatz der CPU:

root@black:/sys/fs/cgroup/cpu# ps -C yes -opid,%cpu,psr,args
  PID %CPU PSR COMMAND
 3128 83.3   1 yes high
 3129 20.7   1 yes low

Erklären, warum dies funktioniert, ist ein nützlicher Schritt, um herauszufinden, warum das frühere nicht auch funktioniert.

Eine erste Erklärung zu diesem Testfall habe ich von Stefan Seyfried erhalten, der das Papier geschrieben hat, aus dem dieses Beispiel stammt. Das Problem hierbei ist, dass die CPU-Scheduler-Teile von cgroups immer darauf abzielen, die verfügbare CPU ausgelastet zu halten. Es wird niemals ein hartes Limit durchgesetzt, wenn alles auf einmal passt.

In dem Fall, in dem zwei Prozesse (hoch und niedrig hier) auf> = 2 Kernen ausgeführt werden, bleibt es nur auf einem Kern hoch und auf dem anderen niedrig. Beide werden dann die ganze Zeit mit einer Auslastung von nahezu 100% ausgeführt, da sie dies tun können, ohne die Situation zu treffen, in der der Scheduler ihnen nicht genügend Zeit auf der CPU gibt. Die Planung von cpu.share erfolgt nur, wenn ein Mangel vorliegt.

Im zweiten Fall sind beide Prozesse an dieselbe CPU gebunden. Dann muss die CPU-Sharing-Logik etwas Nützliches mit den relativen cpu.shares-Zahlen tun, um sie auszugleichen, und dies geschieht wie erhofft.

Harte Einschränkungen der CPU-Auslastung werden wahrscheinlich erst angezeigt, nachdem der Patch zur CFS-Bandbreitensteuerung veröffentlicht wurde . An diesem Punkt könnte es möglich sein, etwas ähnlicheres zu bekommen, wie ich es mir erhofft hatte.