CPU亲和力如何与Linux中的cgroups交互？

我试图在一组隔离的CPU上运行multithreading基准testing。长话短说，我最初尝试使用isolcpus和taskset ，但遇到了问题。现在我正在玩cgroups / cset。

我认为“简单的” cset shield用例应该很好地工作。我有4个核心，所以我想使用核心1-3进行基准testing（我也将这些核心configuration为自适应刻度模式），然后核心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

所以现在我们有一个孤立的“盾牌”（用户密码）和核心0是其他任何东西（系统密码）。

好吧，看起来不错。现在让我们看看htop 。这些进程应该都已经迁移到CPU 0上：

csets

咦？一些过程显示为在屏蔽内核上运行。为了排除htop有bug的情况，我也尝试使用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 affinities（ htop / taskset ）或cset ？

我怀疑你不应该使用cset和affinities在一起。也许盾牌工作正常，我应该忽略亲和力掩模和htop输出。无论哪种方式，我觉得这很混乱。有人能发光吗？

从cpusets文档：

对sched_setaffinity的调用将被过滤为该任务的cpuset中允许的那些CPU。

这意味着CPU关联掩码与进程所属的cgroup中的cpus相交。

例如，如果进程的关联掩码包括核心{0,1,3}，并且进程正在限制为核心{1,2}的系统cgroup上运行，则该进程将被强制在核心1上运行。

我99％确定htop输出是错误的，因为cgroups创build后进程没有被唤醒，显示器显示了进程运行的最后一个核心。

如果我在制作盾牌之前启动vim，vim会分叉两次（出于某种原因），而最深的小孩正在核心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上运行：即相交（{0,1,2,3}，{0}）= {0}。

如果可以的话，我会把问题留出一段时间，看看是否有更好的答案。

感谢@davmac帮助（irc）。