Как сходство ЦП взаимодействует с cgroups в 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. Все процессы должны быть перенесены на CPU 0:

А? Некоторые процессы показаны работающими на экранированных ядрах. Чтобы исключить случай, когда htop имеет ошибку, я также попытался использовать, tasksetчтобы проверить маску аффинности процесса, показанного как находящийся в щите.

Может быть, эти задачи были неподвижны? Давайте подключим произвольный процесс, показанный как выполняющийся на CPU3 (который должен быть в экране), htopи посмотрим, появится ли он в системной группе в соответствии с cset:

$ cset shield -u -v | grep 864
   root       864     1 Soth [gmain]
   vext01    2412  2274 Soth grep 864 

Да, это работает в системе cgroup в соответствии с cset. Так htopи csetне согласен.

Так что здесь происходит? Кому я доверяю: сродство процессора ( htop/ taskset) или cset?

Я подозреваю, что вы не должны использовать csetи сходство вместе. Возможно, щит работает нормально, и я должен игнорировать маски сродства и htopвывод. В любом случае, я нахожу это запутанным. Может кто-нибудь пролить свет?

Из документации по процессорам :

Вызовы sched_setaffinity фильтруются только для тех процессоров, которые разрешены в процессоре этой задачи.

Это подразумевает, что маски соответствия процессоров пересекаются с процессором в cgroup, членом которой является процесс.

Например, если маска соответствия процесса включает в себя ядра {0, 1, 3} и процесс выполняется в системной cgroup, которая ограничена ядрами {1, 2}, то процесс будет принудительно запущен на ядре 1.

Я на 99% уверен, что htopвывод «неправильный», потому что процессы не проснулись с момента создания cgroups, и на дисплее отображается последнее ядро, на котором запущен процесс.

Если я запускаю 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 из-за cgroups: т.е. пересечение ({0,1,2,3}, {0}) = {0}.

Если я смогу, я оставлю вопрос открытым некоторое время, чтобы посмотреть, появится ли лучший ответ.

Спасибо @davmac за помощь в этом (на irc).