我想问一下，我所观察到的行为的解释 是否正确 。
行为 ：重新启动cgconfig守护进程后，进程具有正确的核心关系（由tasksetvalidation），但是线程最终与所有核心（在我们的例子中为0-35，也由tasksetvalidation）结束。
解释 ：closurescgconfig守护进程卸载/ 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挂载产生这个过程：
$ 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中。
环境 ：红帽企业Linux服务器版本6.8（圣地亚哥）