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

一連の分離されたCPUでマルチスレッドベンチマークを実行しようとしています。長い話を短くカットするには、私が最初にしてみましたisolcpusとtaskset、しかし、ヒットの問題を。今、私はcgroups / csetsで遊んでいます。

「単純な」cset shieldユースケースはうまく機能すると思います。私は4つのコアを持っているので、ベンチマークにコア1〜3を使用します（これらのコアもアダプティブティックモードに設定しました）。その後、コア0を他のすべてに使用できます。

ここのチュートリアルに従うと、次のように簡単になります。

$ 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するために、シールドに表示されているプロセスのアフィニティマスクを調べてみました。

多分それらのタスクは移動できませんでしたか？CPU3（シールド内にあるはずです）で実行されていると示されている任意のプロセスを取り出しhtopて、システムのcgroupに表示されるかどうかを確認しますcset。

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

うん、それはによるとシステムcgroupで実行されていますcset。だから、htopとcset反対します。

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

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

cpusetsのドキュメントから：

sched_setaffinityの呼び出しは、そのタスクのcpusetで許可されているCPUのみにフィルタリングされます。

これは、CPUアフィニティマスクが、プロセスがメンバーであるcgroupのcpusと交差していることを意味します。

たとえば、プロセスのアフィニティマスクにコア{0、1、3}が含まれ、プロセスがコア{1、2}に制限されているシステムcgroupで実行されている場合、プロセスはコア1で強制的に実行されます。

htopcgroupが作成されてからプロセスが起動しなかったという事実と出力が「間違っている」と99％確信しています。ディスプレイには、プロセスが実行された最後のコアが表示されています。

シールドを作成する前にvimを開始すると、vimは2回（何らかの理由で）フォークし、最も深い子がコア2で実行されます。その後、シールドを作成してからvimをスリープ（ctrl + z）してスリープ解除すると、両方のプロセスでコア0に移動しました。これは、htop古い情報を示している仮説を裏付けていると思います。

フィールドを調べ/proc/<pid>/statusて確認することもできcpus_allowed_*ます。

例えば私が持っているconsole-kit-daemon、ここでコア3上で実行されているようhtopので示すが、プロセスは（857 PID） /proc/857/status：

Cpus_allowed:   1
Cpus_allowed_list:      0

これは、アフィニティマスクが0x1であることを示していると思います。これは、cgroupsによってコア1でのみ実行できることを意味します。つまり、intersect（{0,1,2,3}、{0}）= {0}です。

できれば、質問を開いたままにして、より良い答えが出てくるかどうかを確認します。

（irc上で）これを手伝ってくれた@davmacに感謝します。