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

概述我正在尝试在一组隔离的CPU上运行多线程基准测试.简而言之,我最初尝试使用isolcpus和taskset,但是打了 problems.现在我正在使用cgroups / csets. 我认为“简单”的cset shield用例应该可以很好地工作.我有4个核心,所以我想使用核心1-3进行基准测试(我还将这些核心配置为自适应滴答模式),然后核心0可用于其他所有内容. 按照教程here,它应该如下所示： 我正在尝试在一组隔离的cpu上运行多线程基准测试.简而言之,我最初尝试使用isolcpus和taskset,但是打了 problems.现在我正在使用cgroups / csets.

我认为“简单”的cset shIEld用例应该可以很好地工作.我有4个核心,所以我想使用核心1-3进行基准测试(我还将这些核心配置为自适应滴答模式),然后核心0可用于其他所有内容.

按照教程here,它应该如下所示：

$sudo cset shIEld -c 1-3cset: --> shIElding modifIEd with:cset: "system" cpuset of cpuSPEC(0) with 105 tasks runningcset: "user" cpuset of cpuSPEC(1-3) with 0 tasks running

所以现在我们有一个隔离的“屏蔽”(用户cset)和核心0用于其他一切(系统cset).

好吧,到目前为止看起来不错.现在让我们来看看htop.这些进程都应该已迁移到cpu 0上：

咦？某些过程显示为在屏蔽核心上运行.为了排除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亲缘关系(htop / taskset)或cset？

我怀疑你不应该一起使用cset和亲和力.也许屏蔽工作正常,我应该忽略亲和面具和htop输出.不管怎样,我发现这令人困惑.有人可以解雇一些吗？

解决方法 从 cpusets documentation：

Calls to sched_setaffinity are filtered to just those cpus allowed
in that task’s cpuset.

这意味着cpu亲和力掩码与进程所属的cgroup中的cpus相交.

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

我99％确定htop输出对于自创建cgroup以来进程尚未唤醒的事实是“错误的”,并且显示器显示进程运行的最后一个核心.

如果我在制作盾牌之前启动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:   1cpus_allowed_List:      0

我认为这是说亲和掩码是0x1,由于cgroups,它只允许在核1上运行：即intersect({0,2,3},{0})= {0}.

如果可以,我会暂时搁置这个问题,看看是否有更好的答案.

感谢@davmac帮助解决这个问题(在irc上).

总结

以上是内存溢出为你收集整理的CPU亲和力如何与Linux中的cgroup交互？全部内容，希望文章能够帮你解决CPU亲和力如何与Linux中的cgroup交互？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。