web-dev-qa-db-ja.com

LinuxでCPUアフィニティはcgroupとどのように相互作用しますか?

一連の分離されたCPUでマルチスレッドベンチマークを実行しようとしています。長い話を短くするために、私は最初にisolcpustasksetを試しましたが、 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に移行されているはずです。

csets

えっ?一部のプロセスは、シールドされたコアで実行されているように示されています。 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で実行されています。したがって、htopcsetは一致しません。

ここで何が起こっているのでしょうか?私は誰を信頼しますか:CPUアフィニティ(htop/taskset)またはcset

csetとaffinitiesを一緒に使用することは想定されていません。おそらくシールドは正常に機能しており、アフィニティマスクとhtop出力を無視する必要があります。いずれにせよ、これは混乱を招きます。誰かが光を当てることはできますか?

10
Edd Barrett

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>/statuscpus_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に感謝します。

5
Edd Barrett