我想问一下我的解释我观察到的行为是正确的。
行为：重新启动 cgconfig 守护进程后，进程具有正确的核心亲和性（经 taskset 验证），但线程最终对所有核心具有亲和性（在我们的例子中为 0-35，也经 taskset 验证）。
说明：关闭 cgconfig 守护进程会卸载 /cgroup 文件系统。这会将所有进程放入 ROOT cgroup 中。重新启动 cgconfig 时，它会将正确的 cgroup 应用于进程，但不应用于线程。
证据：我执行了以下命令来找出谁在“隔离”的核心 19 上运行：
ps -eL -o "tid,pid,psr"| grep "19$"
那里应该只有一个非内核线程在运行，但是我看到有很多这样的线程。
例子：
180978 180957 19
检查这个 tid/pid，我看到了以下线程：
$ taskset -pc 180978
pid 180978's current affinity list: 0-35
这是过程
$ taskset -pc 180957
pid 180957's current affinity list: 1,3-18,20-28,30,32,33,35
因此线程最终以某种方式与进程具有不同的亲和力。
此外，查看 /cgroup mount 可得到以下进程：
$ find /cgroup/cpuset -name tasks | xargs grep 180957
/cgroup/cpuset/appXXX/XXXcommon/tasks:180957
这是线程：
$ find /cgroup/cpuset -name tasks | xargs grep 180978
/cgroup/cpuset/tasks:180978
因此我们可以看到该线程以某种方式最终进入了根组。
重申：有人可以确认或否认重新启动 cgconfig 守护进程会正确设置进程的 cgroup，但会将线程留在根 cgroup 中。
环境：Red Hat Enterprise Linux Server 版本 6.8（圣地亚哥）