我认为“简单”的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输出.不管怎样,我发现这令人困惑.有人可以解雇一些吗？
解决方法
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: 1 cpus_allowed_list: 0
我认为这是说亲和掩码是0x1,由于cgroups,它只允许在核1上运行：即intersect({0,2,3},{0})= {0}.
如果可以,我会暂时搁置这个问题,看看是否有更好的答案.
感谢@davmac帮助解决这个问题(在irc上).
