Я хотел бы спросить, если мой объяснение поведения, которое я наблюдаю правильно.
Поведение: После перезапуска демона cgconfig процессы имеют правильную привязку к ядру (как проверено набором задач), но потоки в конечном итоге имеют привязку ко ВСЕМ ядрам (в нашем случае 0-35, также как проверено набором задач).
Объяснение: Завершение работы демона cgconfig размонтирует файловую систему / cgroup. Это помещает все процессы в контрольную группу ROOT. При перезапуске cgconfig применяет правильную контрольную группу к процессам, но не к потокам.
Доказательство: Я выполнил следующую команду, чтобы узнать, кто работает на "изолированном" ядре 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 правильно устанавливает контрольные группы для процессов, но оставляет потоки в корневой контрольной группе.
Окружающая среда: Red Hat Enterprise Linux Server, выпуск 6.8 (Сантьяго)