Як афінність процесора взаємодіє з групами в 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), а core 0 - для всього іншого (системний комплект).

Добре, поки добре виглядає. Тепер давайте розглянемо 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не згоден.

То що тут відбувається? Кому я довіряю: CPU афіні ( htop/ taskset) або cset?

Я підозрюю, що ви не повинні використовувати csetта спорідненість разом. Можливо, щит працює чудово, і я повинен ігнорувати маски спорідненості та htopвихід. Так чи інакше, я вважаю це заплутаним. Може хтось пролити трохи світла?

З документації на cpusets :

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

Це означає, що маски афінності CPU перетинаються з cpus у групі, учасником якої є процес.

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

Я на 99% впевнений, що htopвисновок "неправильний" у тому, що процеси не прокинулися з моменту створення груп, і на дисплеї відображається останнє ядро, на якому запускався процес.

Якщо я запускаю 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).