Каковы последствия, если таковые имеются, приоритетов планировщика и политик для потоков в непреднамеренном процессоре?

У меня есть система Linux, где мы использовали cgroups для создания двух cpuse_exclusive cpusets, и где мы перенесли все пользовательские потоки и все несвязанные потоки ядра в cgroup, присоединенную к cpuset A. Вещи, работающие в cpuset A, имеют различные политики планировщика и различные приоритеты, и в процессоре A работает намного больше потоков, чем в процессоре A.

Существует также небольшое количество очень активных процессов, подключенных к процессору B, где общее число пользовательских потоков в этих процессах никогда не превышает число ядер, доступных исключительно в процессоре B. Цель состоит в том, чтобы защитить эти важные задачи, выполняемые в процессоре cpuset. B от другой деятельности на машине и минимизировать задержку обработки.

При такой настройке имеет ли какой-либо заметный эффект политика / приоритет планирования пользовательских потоков, работающих в процессоре B? Другими словами: будет ли изменение политики планирования потоков B-процессоров с SCHED_OTHER по умолчанию на SCHED_FIFO или SCHED_RR иметь какие-либо последствия, хорошие или плохие?

Кажется, что ответ должен быть «нет», так как планировщик должен иметь возможность назначать каждому потоку, выполняющемуся в cpuset B, свое собственное выделенное ядро, поэтому не будет ничего, чтобы расставлять приоритеты или планировать, и поэтому политика и относительный приоритет B Темы cpuset не имеют значения. С другой стороны, существуют связанные с ним потоки ядра и аспекты «домена планировщика», и, возможно, другие вещи, которые я не учел.

Имеют ли какое-либо практическое значение политики планирования и приоритеты потоков, запущенных в сверхпоставленном эксклюзивном процессоре?

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

Вы можете использовать schedtool для установки политики конкретных PID для всех PID в наборе B в виде одной команды. Его также можно использовать для привязки определенных PID к конкретным ядрам, что было бы оптимальным решением, поскольку постоянство кэша больше не зависит от временного интервала, но для этого требуется больше усилий, поскольку для каждого PID необходимо выполнить отдельную команду schedtool.

Если у каждого процесса есть свое ядро, то нет никаких приоритетов.

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

Однако нет «лучшей» политики планирования.

Они действительно зависят от того, чего вы хотите достичь. Но вначале я бы оставил SCHED_OTHER по умолчанию и некоторое время наблюдал, прежде чем пытаться специализироваться.