Как привязка процессора взаимодействует с контрольными группами в Linux?
Я пытаюсь запустить многопоточные тесты на наборе изолированных процессоров. Короче говоря, я сначала попробовал с isolcpus и taskset, но ударил проблемы. Сейчас играю с cgroups / csets.
Я думаю "простой" cset shield вариант использования должен работать нормально. У меня 4 ядра, поэтому я хотел бы использовать ядра 1-3 для тестирования (я также настроил эти ядра для работы в режиме адаптивных тиков), тогда ядро 0 можно использовать для всего остального.
Следуя руководству Вот, это должно быть так просто, как:
$ 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. Все процессы должны быть перенесены на ЦП 0:
А? Некоторые процессы показаны как выполняющиеся на экранированных ядрах. Чтобы исключить случай, когда в htop есть ошибка, я также попытался использовать taskset чтобы проверить маску сродства процесса, показанного как находящийся в щите.
Может быть, эти задачи нельзя было двигать? Давайте возьмем произвольный процесс, показанный как работающий на CPU3 (который должен быть в щите) в htop и посмотрите, появляется ли он в системной контрольной группе в соответствии с cset:
$ cset shield -u -v | grep 864
root 864 1 Soth [gmain]
vext01 2412 2274 Soth grep 864
Да, это работает в системной контрольной группе согласно cset. Так htop и cset не согласен.
Так что здесь происходит? Кому я доверяю: сходство с процессорами (htop/taskset) или cset?
Я подозреваю, что вы не должны использовать cset и сходство вместе. Возможно, щит работает нормально, и мне следует игнорировать маски близости и htop вывод. В любом случае, меня это сбивает с толку. Может кто-нибудь пролить свет?
Вызовы sched_setaffinity фильтруются только для тех процессоров, которые разрешены в процессоре этой задачи.
Это означает, что маски сродства ЦП пересекаются с процессором в контрольной группе, членом которой является процесс.
Например. Если маска сродства процесса включает ядра {0, 1, 3} и процесс выполняется в системной контрольной группе, которая ограничена ядрами {1, 2}, то процесс будет принудительно запущен на ядре 1.
Я на 99% уверен, что htop вывод "неверен", поскольку процессы не проснулись с момента создания контрольных групп, и на дисплее отображается последний core, на котором работал процесс.
Если я запускаю 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, что позволяет работать только на ядре 1 из-за контрольных групп: т.е. пересечь ({0,1,2,3}, {0}) = {0}.
Если можно, я оставлю вопрос открытым, чтобы посмотреть, не появится ли лучший ответ.
Спасибо @davmac за помощь в этом (на irc).