Linux cgroupを使用してCPUパフォーマンスのバランスをとる

比較的最近のカーネルでLinux cgroupを使用して2つのデュアルコアLinuxシステムをインストールしています。1つはDebian Squeezeを実行しており、もう1つはUbuntu 11.04 Natty Narwhalを実行しています。古いカーネルにもかかわらず、Debianシステム上でcgroupの動作が少し改善され、CPUの負荷分散が実現しました。しかし、それはすべてに適しているわけではなく、ここで私が尋ねている特異な奇妙さは両方のシステムで起こります。

コントロールグループを使用したLinuxのリソース管理を読むと、問題の再現方法を示す例が示されています。Ubuntuバージョンは次のとおりです（これをルートとして実行します）。

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

「高」プロセスには「低」プロセスよりも多くの時間が割り当てられると予想していました。このテストケースで実際に起こることは、常に次のようなものです。

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

時間がほぼ等しい場合。ここに私の質問があります：なぜそれが起こっているのですか？

プレゼンテーションでは、この問題は各プロセスを同じCPUに固定することで解消されることが示されています。それをテストするための追加行：

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

その結果は、私が常に見ると期待していたものです：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

これがなぜ機能するのかを説明することは、なぜ以前の機能も機能しないのかを理解するための有用なステップになるでしょう。

このテストケースについて最初に説明したのは、この例が取り上げられた論文を書いたStefan Seyfried氏です。ここでの問題は、cgroupのCPUスケジューラー部分が常に、使用可能なCPUをビジーに保つことを目指していることです。すべてが一度に適合する場合、ハードリミットを強制することはありません。

2つのプロセス（ここでは高と低）が2以上のコアで実行されている場合、一方のコアでは高を、もう一方のコアでは低を維持します。スケジューラがCPUに十分な時間を与えないという状況にぶつかることなく実行できるため、両方ともほぼ100％の使用率で常に実行されます。cpu.shareのスケジューリングは、不足がある場合にのみ発生します。

2番目のケースでは、両方のプロセスが同じCPUに固定されています。次に、CPU共有ロジックは、相対的なcpu.shares番号を使用してそれらのバランスをとるのに役立つ何かをする必要があります。

CPU使用率の厳しい制限は、CFS帯域幅制御パッチがヒットするまで表示されない可能性があります。その時点で、私が望んでいたもののようなものを手に入れることができるかもしれません。