一連の分離されたCPUでマルチスレッドベンチマークを実行しようとしています。長い話を短くするために、私は最初にisolcpus
とtaskset
を試しましたが、 problems を押しました。今、私はcgroups/csetsで遊んでいます。
「シンプル」だと思いますcset shield
ユースケースはうまく機能するはずです。私は4つのコアを持っているので、ベンチマークにコア1〜3を使用します(これらのコアを適応ティックモードに設定しました)。それ以外の場合はコア0を使用できます。
チュートリアル here に従うと、次のように簡単になります。
$ 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
これで、分離された「シールド」があり(ユーザーcset)、コア0はそれ以外のすべてのもの(システムcset)になります。
よし、これまでのところよさそうだ。では、htop
を見てみましょう。プロセスはすべてCPU 0に移行されているはずです。
えっ?一部のプロセスは、シールドされたコアで実行されているように示されています。 htopにバグがあるケースを除外するために、taskset
を使用して、シールド内にあると示されているプロセスのアフィニティマスクを検査してみました。
多分それらのタスクは移動できませんでしたか? htop
のCPU3(シールド内にあるはず)で実行されている任意のプロセスを取り出し、cset
に従ってシステムのcgroupに表示されるかどうかを確認してみましょう。
$ cset shield -u -v | grep 864
root 864 1 Soth [gmain]
vext01 2412 2274 Soth grep 864
うん、それはcset
に従ってシステムcgroupで実行されています。したがって、htop
とcset
は一致しません。
ここで何が起こっているのでしょうか?私は誰を信頼しますか:CPUアフィニティ(htop
/taskset
)またはcset
?
cset
とaffinitiesを一緒に使用することは想定されていません。おそらくシールドは正常に機能しており、アフィニティマスクとhtop
出力を無視する必要があります。いずれにせよ、これは混乱を招きます。誰かが光を当てることはできますか?
cpusetsのドキュメント から:
Sched_setaffinityの呼び出しは、そのタスクのcpusetで許可されているCPUのみにフィルタリングされます。
これは、CPUアフィニティマスクが、プロセスがメンバーであるcgroupのcpusと交差していることを意味します。
例えば。プロセスのアフィニティマスクにコア{0、1、3}が含まれ、プロセスがコアc1、2、}に制限されているシステムcgroupで実行されている場合、プロセスはコア1で強制的に実行されます。
htop
の出力がcgroupが作成されてからプロセスが起こらなかったという事実と「間違っている」ことを99%確信しており、ディスプレイにはと表示されていますプロセスが実行されたlastコア。
シールドを作成する前にvimを開始すると、vimは(何らかの理由で)2回フォークし、最も深い子がコア2で実行されます。その後、シールドを作成してからvimをスリープ(ctrl + z)してスリープ解除すると、両方のプロセスでコア0に移動しました。これは、htop
が古い情報を示しているという仮説を裏付けていると思います。
検査することもできます/proc/<pid>/status
とcpus_allowed_*
田畑。
例えば。 console-kit-daemon
プロセス(pid 857)は、htopではコア3で実行されているように表示されますが、/proc/857/status
:
Cpus_allowed: 1
Cpus_allowed_list: 0
これは、アフィニティマスクが0x1であることを示していると思います。これは、cgroupsにより、コア1でのみ実行できることを意味します。つまり、intersect({0,1,2,3}、{0})= {0}です。
できれば、質問を開いたままにして、より良い答えが出てくるかどうかを確認します。
(irc上で)これを手伝ってくれた@davmacに感謝します。