CPU亲和力如何与Linux中的cgroup交互？
|
我正在尝试在一组隔离的CPU上运行多线程基准测试.简而言之,我最初尝试使用isolcpus和taskset,但是打了
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上： 咦？某些过程显示为在屏蔽核心上运行.为了排除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：
这意味着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: 1 Cpus_allowed_list: 0 我认为这是说亲和掩码是0x1,由于cgroups,它只允许在核1上运行：即intersect({0,2,3},{0})= {0}. 如果可以,我会暂时搁置这个问题,看看是否有更好的答案. 感谢@davmac帮助解决这个问题(在irc上). （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |