Классы и приоритеты процессов Linux

Переключение центрального процессора между задачами (процессами и нитями) выполняет специальная компонента подсистемы управления процессами, называемая планировщиком (scheduler). Именно планировщик определенным образом выбирает из множества неспящих, готовых к выполнению (runable) задач одну, которую переводит в состояние выполнения (running).

Процедуры, определяющие способ выбора и моменты выполнения выбора, называются алгоритмами планирования. Выбор задачи, подлежащей выполнению, естественным образом происходит в моменты времени, когда текущая выполнявшаяся задача переходит в состояние сна (sleep) в результате выполнения операции ввода-вывода.

Вытесняющие алгоритмы планирования, кроме всего прочего, ограничивают непрерывное время выполнения задачи, принудительно прерывая ее выполнение по исчерпанию выданного ей кванта времени (timeslice) и вытесняя ее во множество готовых, после чего производят выбор новой задачи, подлежащей выполнению.

По умолчанию для пользовательских задач используется вытесняющий алгоритм CFS (completely fair scheduler), согласно которому процессорное время распределяется между неспящими задачами справедливым (fair) образом.

Для каждой задачи определяется выделяемая справедливая (в соответствии с ее относительным «приоритетом») доля процессорного времени, которую она должна получить при конкуренции за процессор. Для двух задач с любыми одинаковыми приоритетами должны быть выделены равные доли (в 50% процессорного времени), а при различии в приоритетах на одну ступень разница между выделяемыми долями должна составить ≈10% процессорного времени (т. е. 55 и 45% соответственно).

Для удовлетворения этого требования алгоритм планирования CFS назначает каждой ступени приоритета соответствующий «вес» задачи, а процессорное время делит между всеми неспящими задачами пропорционально их весам. Шкала весов учитывает только требование 10% разницы между двумя задачами с различием в относительных приоритетах на одну ступень.

Таким образом, две задачи с любыми одинаковыми приоритетами будут иметь равные веса w_i =w_j = w,  а доли процессорного времени составят μ_i, = w_i /(w_i + w_j) — 1/2 и μ_j = w/(w_i + w_j) = 1/2. Для двух задач с приоритетами, отличающимися на одну ступень w_i ≠ w_j, а μ_i — μ_j = 1/10, откуда несложно получить, что w_i /w_j = 11/9 — правило построения шкалы весов, а μ_i = 11/20 = 0,55 и μ₂ = 9/20 = 0,45, что и требовалось получить.

Для дифференциации задач используют 40 относительных POSIX-приоритетов на шкале от —20 до +19, называемых «любезностью» задачи NICE.

Относительный приоритет буквально определяет, насколько «любезна» будет задача по отношению к остальным готовым к выполнению задачам при конкуренции за процессорное время освободившегося процессора. Наименее «любезным»с относительным приоритетом —20 (наивысшим) планировщик выделит большую долю процессорного времени, а наиболее «любезным», с приоритетом +19 (наинизшим) – меньшую.

При отсутствии конкуренции, когда количество готовых к выполнению задач равно количеству свободных процессоров, приоритет не будет играть никакой роли.

В примере из листинга ниже при помощи команды bzip запущены два процесса сжатия ISO-образа с наилучшим качеством одновременно друг другу на «заднем фоне». В выводе свойств pcpu (percent cpu, процент потребляемого процессорного времени), pri (priority), ni (nice) и psr (processor number) их процессов при помощи ps оказывается, что они потребляют практически одинаковые доли (проценты) процессорного времени, и это для одинаковых программ вполне соответствует интуитивным ожиданиям.

После повышения любезности (понижения относительного приоритета) одного из них в при помощи команды renice до значения +10 отношение потребляемых долей процессорного времени не изменилось, что означает отсутствие конкуренции за процессор, подтверждаемое как столбцом PSR, доказывающим номер процессора, выполняющего программу, так и командами nproc и lscpu.

Относительный приоритет NICE

Проиллюстрировать действие относительного приоритета NICE на многопроцессорной системе можно, создав искусственную конкуренцию двух процессов за один процессор. Для этого при помощи команды taskset устанавливается привязка (affinity) командного интерпретатора (PID=12808) к процессору 3 (привязка, как и прочие свойства и атрибуты процесса, наследуется потомками).

Затем при помощи команды nice запускаются две программы упаковки с относительными приоритетами 5 и 15 в режиме измерения потребления времени при помощи команды time. В результате доли процессорного времени распределяются неравномерно, причем их разница зависит от разницы в относительных приоритетах (и от свойств конкурирующих процессов, но в примере они одинаковые). Дождавшись завершения процессов заднего фона, при помощи встроенной команды wait можно оценить разницу в реальном времени выполнения упаковки, вызванную неравным распределением процессора между процессами упаковщиков.

Кроме приоритетной очереди, планировщик Linux позволяет использовать еще два алгоритма планирования — FIFO и RR, предназначенные для задач реального времени. Вытесняющий алгоритм RR (round robin) организует простейшее циклическое обслуживание с фиксированными квантами времени, тогда как FIFO (first in first out) является его невытесняющей модификацией, позволяя задаче выполняться непрерывно долго, до момента ее засыпания. По сути, оба алгоритма организуют задачи в одну приоритетную очередь (PQ, priority queue) со статическими приоритетами на шкале от 1 до 99, выбирая для выполнения всегда самую высокоприоритетную из множества готовых.

Перевод задачи под управление тем или алгоритмом планирования производится при помощи назначения ей политики планирования (scheduling policy) посредством команды chrt. Различают пять политик планирования, три из которых — SCHED_OTHER, SCHED_BATCH и SCHED_IDLE — реализуются алгоритмом CFS, а две оставшиеся — SCHED_FIFO, SCHED_RR — одноименными алгоритмами FIFO и RR. Политика SCHED_OTHER, она же SCHED_NORMAL, применяется по умолчанию и обслуживает класс задач TS (time sharing), требующих «интерактивности», а политика SCHED_BATCH предназначается для выполнения «вычислительных» задач класса пакетной В (batch) обработки.

Разница между политиками состоит в том, что планировщик в случае необходимости всегда прерывает задачи класса В в пользу задач класса TS, но никогда наоборот. Политика SCHEDJDLE формирует класс задач, выполняющихся только при «простое» (idle) центрального процессора за счет выделения им планировщиком CFS очень небольшой доли процессорного времени. Для этого задачам IDL-класса назначают минимально возможный вес — меньший, чем вес самых «любезных» (NICE = +19) задач TS -класса.

В примере из листинга ниже проиллюстрировано распределение процессорного времени алгоритмом планирования CFS между (конкурирующими за один процессор) одинаковыми процессами TS-, В- и IDL-классов, назначенных им при запуске упаковщиков bzip2 посредством команды chrt.

Классы процессов

В листинге ниже показана конкуренция процессов под управлением RR-планировщика, использующего статические приоритеты. Так как операция назначения политик планирования «реального времени» FIFO и RR является привилегированной, то сначала командный интерпретатор переводится в RR-класс (-r) с наивысшим статическим приоритетом 99 при помощи команды chrt, выполняемой от липа суперпользователя root.

При последующих запусках упаковщиков класс будет унаследован и не потребует повышенных привилегий. Два процесса упаковщиков запускаются  командой chrt с одинаковыми статическими приоритетами 1, при вязанные к одному процессору командой tdskset, в результате чего получают равные доли процессорного времени, что вполне соответствует интуитивным ожиданиям от вытесняющего циклического планировщика RR.

Нужно отметить, что шкала статических приоритетов 1—>99 классов RR и FIFO, как и шкала «любезности» NICE +19->-20 классов TS и В, отображаются на общую шкалу приоритетов PRI так, что верхняя часть шкалы PRI: 41—>139 соответствует статическим приоритетам, а нижняя часть шкалы PRI: 0—>39 соответствует «любезности».

Классы процессов реального времени

Добавление третьего процесса упаковщика со статическим приоритетом 2 приводит к резкому перекосу выделяемой доли процессорного времени в его пользу. Это объясняется тем, что алгоритм планирования RR (равно как и FIFO) всегда выбирает процесс с самым высоким статическим приоритетом из множества готовых, поэтому процессам с более низкими приоритетами процессорное время будет выделено только при засыпании всех процессов с большими приоритетами. А упаковщик, хоть и выполняет операции ввода-вывода, в реальности практически не засыпает № связи с использованием дискового кэша.

Странный результат, изображаемый командой ps, объясняется «несовершенством» ее способа расчета доли процессорного времени %CPU, выделяемой процессу. Расчет производится как отношение чистого потребленного процессорного времени (за все время существования процесса) к промежутку реального времени, прошедшему с момента порождения процесса, что соответствует среднему, но не мгновенному значению потребляемой доли.

Гораздо более ожидаемый результат получает команда top, выполняющая расчет мгновенной доли процессорного времени как отношение чистого потребленного процессорного времени (за небольшой промежуток наблюдения) к реальному времени наблюдения.