Gostaria de perguntar se minha explicação do comportamento que observo está correta .
O comportamento : Depois de reiniciar o daemon cgconfig, os processos têm afinidade core correta (como verificado pelo taskset), mas os threads acabam com afinidade para todos os núcleos (0-35 no nosso caso, também como verificada pelo taskset).
A explicação : Desligar o daemon cgconfig desmonta o sistema de arquivos / cgroup. Isso coloca todos os processos no cgroup ROOT. Quando o cgconfig é reiniciado, ele aplica o cgroup correto aos processos, mas não aos threads.
A evidência : executei o seguinte comando para descobrir quem está executando no núcleo "isolado" 19:
ps -eL -o "tid,pid,psr"| grep "19$"
Apenas um segmento não-kernel deve estar sendo executado lá, mas vejo muitos deles.
Exemplo:
180978 180957 19
Verificando este tid / pid, vejo isso para o tópico:
$ taskset -pc 180978
pid 180978's current affinity list: 0-35
E isso para o processo
$ taskset -pc 180957
pid 180957's current affinity list: 1,3-18,20-28,30,32,33,35
Então, o segmento de alguma forma acabou com uma afinidade diferente do processo.
Além disso, a pesquisa em / cgroup mount gera isso para o processo:
$ find /cgroup/cpuset -name tasks | xargs grep 180957
/cgroup/cpuset/appXXX/XXXcommon/tasks:180957
E isso para discussão:
$ find /cgroup/cpuset -name tasks | xargs grep 180978
/cgroup/cpuset/tasks:180978
Assim, podemos ver que o segmento de alguma forma acabou no grupo raiz.
Para reiterar : alguém poderia confirmar ou negar que o reinício do daemon cgconfig define os cgroups para processos corretamente, mas deixa os threads no cgroup raiz.
Ambiente : Servidor Red Hat Enterprise Linux versão 6.8 (Santiago)