Linux CFS Волонтерские контекстные коммутаторы SCHED_OTHER SCHED_FIFO

Question

Я занимаюсь анализом CFS Linux для своего класса ОС и наблюдаю за тем, что не могу объяснить.

Для двух других идентичных процессов, когда они выполняются с помощью политики SCHED_OTHER, я вижу примерно на 50% больше добровольных переключателей контекста, чем когда я выполняю их с помощью политики SCHED_FIFO или SCHED_RR.

Это не удивило бы меня для непроизвольных выключателей, поскольку SCHED_OTHER имеет гораздо более низкий приоритет, поэтому он должен отказаться от процессора. Но почему это будет так для добровольными переключателями. Почему SCHED_OTHER добровольно отказывается от процессора чаще, чем процессы в реальном времени? Это идентичный процесс, поэтому он только добровольно отказывается от процессора, когда переключается на ввод-вывод, не так ли? И я не думаю, что выбор политики повлияет на частоту попыток ввода-вывода.

У любого человека Linux есть идея? Благодаря!

Answer 1

Сначала следует понимать, что политики планирования - это не что иное, как алгоритмы планирования, реализованные в ядре. Таким образом, SCHED_FIFO, SCHED_RR, SCHED_OTHER - это разные алгоритмы в ядре. SCHED_FIFO и SCHED_RR относятся к алгоритмам реального времени «класс». SCHED_OTHER - не что иное, как алгоритм планирования для нормальных процессов в системе, более широко известный как алгоритм CFS (полностью справедливый планировщик).

SCHED_OTHER имеет гораздо более низкий приоритет

Чтобы быть точным, он не имеет «много» более низкий приоритет, но имеет «» низкий приоритет, чем класс планирования реального времени. Существует три класса планирования в планировщике Linux - планировщик реального времени, класс планирования обычного процесса и класс планирования задач Idle Tasks. Приоритетными являются следующие уровни:

1. Планирование в режиме реального времени.
2. Обычный класс планирования заданий.
3. Idle Tasks Scheduling Class.

Задачи системы относятся к одному из этих классов. (Обратите внимание, что в любой момент времени задача может принадлежать только одному классу планирования, хотя ее класс можно изменить). Планировщик в Linux сначала проверяет, есть ли задача в классе реального времени. Если есть, то он вызывает алгоритм SCHED_FIFO или SCHED_RR, в зависимости от того, что настроено в системе. Если нет заданий в реальном времени, планировщик проверяет нормальные задачи и вызывает алгоритм CFS в зависимости от того, есть ли нормальная задача, готовая к запуску. Также

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

1. Как правило, в простой системе практически нет задач реального времени, и большинство задач относится к классу обычных задач. Таким образом, когда вы запускаете этот процесс в режиме реального времени, вы будете иметь весь процессор для этого процесса исключительно (поскольку класс планирования в реальном времени имеет более высокий приоритет, чем обычный класс планирования задач, и нет (/ очень немного реального) времени задача (ы) для совместного использования ЦП). Когда вы запускаете тот же процесс в обычном классе задач, процесс должен разделить процессор с другими другими процессами, что приводит к большему количеству контекстных переключателей.
2. Даже если в системе много задач реального времени, характер алгоритмов планирования реального времени, FIFO и RR, приводит к более низким контекстным переключателям. В FIFO процессор не переключается на другую задачу до тех пор, пока текущий не будет завершен, а в RR будет установлен фиксированный интервал (кванты времени), который передается процессам. Когда вы смотрите на CFS, время, которое получает процесс, пропорционально количеству задач в runqueue процессора. Это функция его веса и общего веса процессора. Я предполагаю, что вы хорошо разбираетесь в FIFO и RR, так как вы занимаетесь классами ОС. Для получения дополнительной информации о CFS я советую вам это сделать или если вы достаточно храбры, а затем ознакомьтесь с его исходным кодом.

Надежда ответ завершен :)