Які ефекти, якщо такі є, на пріоритети та політики планувальника для потоків безперебійного процесора?

У мене є система Linux, де ми використовували cgroups для створення двох cpu_exclusive cpusets, A і B, і де ми перемістили всі потоки користувачів і всі незв'язані потоки ядра до групи, приєднаної до cpuset A. Речі, що працюють у cpuset A, мають різну політику планувальника і різні пріоритети, і в cpuset A працює набагато більше потоків, ніж ядер у cpuset A.

Існує також невелика кількість дуже активних процесів, приєднаних до cpuset B, де загальна кількість потоків користувачів у цих процесах ніколи не перевищує кількість ядер, доступних виключно в cpuset B. Метою є захист цих важливих завдань, що виконуються в cpuset B від іншої активності на машині та мінімізувати затримку обробки.

Чи має така політика / пріоритет планування користувальницьких потоків, що працюють у cpuset B, якийсь ефект, що спостерігається? Заявлено інакше: чи зміна політики планування потоків B cpuset з типових SCHED_OTHER на SCHED_FIFO або SCHED_RR матиме наслідки, добрі чи погані?

Схоже, що відповідь має бути "ні", оскільки планувальник повинен мати можливість призначити кожному потоку, запущеному в cpuset B, його власне виділене ядро, тому не було б нічого визначати пріоритетів і не планувати, і тому політика та відносний пріоритет B нитки cpuset не мали б значення. З іншого боку, існують пов'язані потоки ядра та "домен планувальника", про які слід турбуватися, і, ймовірно, інші речі, які я не враховував.

Чи мають політику планування та пріоритети потоків, що працюють у надмірно захищеному ексклюзивному процесорі, у будь-якому практичному розумінні?

Використовуваний фрагмент часу буде мати значення для процесів, що вимагають напруженого процесора, які потребують стійкості кешу, якщо ви не заблокуєте певне ядро ​​для кожного PID. Ви можете збільшити часовий відрізок за допомогою політики планування SCHED_BATCH та підвищити продуктивність до 300% у деяких випадках, зменшивши при цьому інтерактивну реакцію. Протилежний ефект менших часових відрізків відбувається з SCHED_RR (що зменшить пропускну здатність, але збільшить швидкість реагування в режимі реального часу).

Ви можете використовувати schedtool для встановлення політики конкретних PID для всіх PID в наборі B як єдину команду. Він також може бути використаний для блокування конкретних PID в конкретних ядрах, що було б оптимальним рішенням, оскільки тоді наполегливість кешу більше не залежить від часового відрізка, але для цього потрібно більше зусиль, оскільки вам потрібно виконати окрему команду schedtool для кожного PID.

Якщо кожен процес має своє ядро, то пріоритетних обмежень немає.

Однак якщо ви заплануєте процес, який займає 30 хвилин, кожні 15 хвилин, у вас виникне потреба в пріоритеті, оскільки процес почне перекриватися.

Однак немає "найкращої" політики планування.

Вони дійсно залежать від того, чого ви хочете досягти. Але на початку я б залишив це SCHED_OTHER, за замовчуванням, і спостерігатиму деякий час, перш ніж спробувати ще більше спеціалізуватися на матеріалах.