CPU亲和力如何与Linux中的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}，并且该进程正在系统cgroup上运行，而该系统cgroup仅限于内核{1，2}，则该进程将被强制在内核1上运行。

我有99％的肯定htop输出是“错误”的事实，因为自创建cgroups以来进程还没有唤醒，并且显示屏显示了进程运行的最后一个核心。

如果在制作防护罩之前先启动vim，则vim会分叉两次（出于某种原因），并且最深的孩子正在核心2上运行。移至核心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}。

如果可以，我将让问题待一会儿，看看是否有更好的答案。

感谢@davmac在irc上提供的帮助。