Планировщиками ос linux являются

7.3.1 Планирование процессов

В предыдущем разделе мы обсуждали детали планировщика Linux. Теперь мы понимаем, как планировщиком управляются задачи реального времени. В этом разделе мы обсудим планировщик по отношению к ядру 2.6. Для определения задачи реального времени в Linux есть три основных параметра:

Они объясняются ниже.

Планировщик Linux предлагает три класса планирования, два для приложений реального времени и один для приложений не реального времени. Этими тремя классами являются:

▪ SCHED_FIFO : политика планирования реального времени первый вошёл, первый вышел (First-In First-Out). Алгоритм планирования не использует никаких интервалов времени. Процесс SCHED_FIFO выполняется до завершения, если он не заблокирован запросом ввода/вывода, вытеснен высокоприоритетным процессом, или он добровольно отказывается от процессора. Следует обратить внимание на следующие моменты:
– Процесс SCHED_FIFO , который был вытеснен другим процессом более высокого приоритета, остаётся во главе списка с его приоритетом и возобновит выполнение, как только все процессы с более высоким приоритетом будут вновь заблокированы.
– Когда процесс SCHED_FIFO готов к работе (например, после пробуждения от операции блокировки), он будет вставлен в конец списка с его приоритетом.
– Вызов sched_setscheduler или sched_setparam поставит процесс SCHED_FIFO в начало списка. Как следствие, это может вытеснить работающий в данный момент процесс, если его приоритет такой же, как и у работающего процесса.

▪ SCHED_RR : циклическая (Round-Robin) политика планирования реального времени. Она похожа на SCHED_FIFO с той лишь разницей, что процессу SCHED_RR разрешено работать как максимум время кванта. Если процесс SCHED_RR исчерпывает свой квант времени, он помещается в конец списка с его приоритетом. Процесс SCHED_RR , который был вытеснен процессом с более высоким приоритетом, завершит оставшуюся часть своего кванта времени после возобновления выполнения.

▪ SCHED_OTHER : стандартный планировщик Linux с разделением времени для процессов, работающих не в реальном времени.

Для установки и получения политики планирования процесса используются функции sched_setscheduler и sched_getscheduler , соответственно.

Диапазоны приоритетов для различных политик планирования показаны в Таблице 7.1. Функции sched_get_priority_max и sched_get_priority_min возвращают максимальный и минимальный приоритет, разрешённый для политики планирования, соответственно. Чем выше число, тем выше приоритет. Таким образом, процесс SCHED_FIFO или SCHED_RR всегда имеет более высокий приоритет, чем процесс SCHED_OTHER . Для процессов SCHED_FIFO и SCHED_RR функции sched_setparam и sched_getparam используются для установки и получения приоритета, соответственно. Для изменения приоритета процессов SCHED_OTHER используется системный вызов nice (или команды).

Таблица 7.1 Диапазон приоритетов в пространстве пользователя

Источник

Linuxoid

OpenSource forever

Планировщики процессов Linux

В статье Планировщики ввода/вывода Linux были рассмотрены планировщики I/O. Еще одной из важных задач по обеспечению нормальной работы любого сервиса, помимо доступа к дисковым устройствам является доступ к процессору. За распределение процессорного времени между работающими приложениями занимаются другие планировщики.

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

Долгое время в Linux присутствовал фактически один scheduler — O(1). Да были другие предложения вроде Staircase от Кона Коливаса (Con Kolivas, http://ck.kolivas.org/patches/pre-releases/2.6.21-rc7/2.6.21-rc7-ck1/patches/ ), с мая 2007 его разработка прекращена. Или Fairsched ( http://s ource f orge .net/projects/fairsched ). Но все они были реализованы исключительно в виде дополнений, не попадая основную ветку. Сегодня наметилась явная активность разработчиков в этом направлении. Сообщения о новых реализациях появляются на KernelTrap чуть ли не ежемесячно.

Стандартному планировщику O(1) уже более 15 лет. В июле 1993 года Линус Торвальдс в своем сообщении ( http://kerneltrap.org/mailarchive/linux-activists/36335 ) описал принцип работы планировщика задач Linux. Оригинальный файл этого планировщика sched.c содержал всего 254 строки кода. Это был простой и понятный алгоритм. В 1996 году нем было уже более 6 тысяч строк. Только через 10 лет в 2002 году первое глобальное изменение ultra-scalable O(1) scheduler от Инго Молнара (Ingo Molnar). В последних версиях sched.c содержит уже более 7000 строк.

Алгоритм работы O(1) очень прост. Каждая задача имела фиксированное число (tick), которое пересчитывается с каждым системным тиком (по умолчанию 100 Hz), при выходе из режима ядра или при появлении более приоритетной задачи. Алгоритм просто делит число на два и добавляет базовую величину (по умолчанию 15, с учетом величины nice ). Когда тик становится равным 0, он пересчитывается. Кроме этого каждый процессор имеет две очереди. В одной находятся готовые к запуску задачи, во вторую помещаются отработавшие и спящие задачи, которые например, ожидают не доступного в настоящее время ресурса. Когда первая очередь пустеет, очереди меняются местами. Поэтому время работы алгоритма постоянно и не зависит от количества процессов. Современная реализация O(1) используют уже более сложные алгоритмы, анализируя среднее время сна процесса, чтобы обнаружить интерактивные задачи ожидающие ответа пользователя и стараясь задержать их подольше в активном дереве.

В ядро 2.6.23 после трех месяцев обкатки в экспериментальной -mm ветке ядра, был включен в качестве основного планировщик CFS (Completely Fair Scheduler, абсолютно справедливый планировщик). Алгоритм которого полностью пересмотрен и весьма сложен. В отличие от O(1) CFS равномернее распределяет процессорное время (фактически если задачи две, то каждая получит ровно 50% CPU), распределяет задачи по нескольким ядрам и имеет меньшее время отклика. Для настройки CFS используется файл /proc/sys/kernel/sched_granularity_ns , в котором по умолчанию установлен режим desktop (меньшее время задержки), но при необходимости его можно переключить в server .

$ cat server > /proc/sys/kernel/sched_granularity_ns

Con Kolivas остановив разработку ветки ck, в марте анонсировал совершенно новый планировщик RSDL (Rotating Staircase DeadLine scheduler), в последствии он был переименован в SD (Staircase Deadline, ck.kolivas.org/patches/staircase-deadline). За его основу был взят Staircase. Задача нового планировщика исключить зависания присущие O(1), здесь все процессы равны, каждому дается своя квота, исчерпав которую он опускается на следующий уровень приоритета, где получает новую квоту. Причем каждый уровень также имеет свою квоту, если ее исчерпает хотя бы один процесс, все перейдут на следующий уровень, в не зависимости от того отработали ли они свою квоту или нет. Планировщик также пытается определить интерактивные процессы, автоматически повышая им приоритет. Версия SD показывала неплохие результаты на серверах, и поговаривали, что этот планировщик будет включен в основную ветку начиная с 2.6.22, но из-за проблем со здоровьем разработка шла относительно медленно и Инго Молнар обогнал соперника.

Как ответ на сложность CFS Роман Зиппель (Roman Zippel) представил рабочий прототип базового алгоритма нового планировщика RFS (Really Fair Scheduler, kerneltrap.org/RFS), который помещает задачу в виртуальную (нормализованную) time line, в которой имеет значение только относительное расстояние между двумя любыми задачами. После некоторых споров в ответ на этот прототип Инго Молнар представил свою версию, которую он назвал RSRFS (Really Simple Really Fair Scheduler) реализованный поверх CFS, и включающий алгоритм из RFS. Есть и патчи к CFS, например programming.kicks-ass.net/kernel-patches/sched-cfs.

За последние 2,5 года было предложено около 300 алгоритмов, так что вряд ли здесь будет спокойно в ближайшее время.

Проект DeskOpt

Интересный проект был представлен примерно полгода назад в списке рассылки разработчиков ядра Linux. Программа DeskOpt (www.stardust.webpages.pl/files/tools/deskopt) представляет собой демон, написанный на языке высокого уровня Python, который отслеживает запускаемые пользователем приложения и автоматически выбирает оптимальные параметры работы планировщика процессов CFS и планировщик ввода/вывода (CFQ, anticipatory, deadline). Все настройки осуществляются путем редактирования конфигурационного файла, в котором по умолчанию описано три класса оптимизации: игры, просмотр видео и прослушивание музыки. Текущая версия 0.6-rc1 от января 2008 года. DeskOpt легко устанавливается

Требования:
— Python 2.x (http://python.org/)
— elementtree (http://effbot.org/downloads/#elementtree)
$ tar xjvf deskopt-006-rc1.tar.bz2

$ cd deskopt-006-rc1

$ cp deskopt /usr/local/bin/
$ sudo mkdir /etc/deskopt/
$ sudo cp deskopt.conf /etc/deskopt/
$ sudo cp deskopt.rc /etc/init.d/

К онфигурационный файл имеет простой XML формат, в нем уже есть готовые настройки. В простейшем случае команда выглядит так:

$ sudo deskopt -c /etc/deskopt/deskopt.conf

2 комментария

Все эти планировщики хороши и разработчикам респект. Но! Применительно к реальной жизни. На сегодня рассматривать можно а) серверы баз данных; б) серверы приложений; в) рабочие станции. Кто бы мог предложить обзор производительности наиболее популярных планировщиков в этих задачах? Уже очень очевидно, что универсального планировщика не создать и потому интересует именно сравнение их между собою с целью выбора оптимального для той или иной задачи. Спасибо.

Источник

Linux в режиме реального времени

Операционная система реального времени необходима, когда к работе процессора или потоку данных предъявляются жесткие временные требования. Таким образом она часто выполняет роль блока управления в специальных устройствах. Проведение научных экспериментов, приложения визуализации в медицине, промышленные устройства управления являются системами реального времени. Механизмы впрыска топлива автомобильных двигателей, контроллеры бытовой и военной техники также являются системами реального времени.

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

Возможности ядра в реальном времени существует уже более десяти лет в экосистеме программ с открытым исходным кодом. Столько же времени доступна поддержка Red Hat Enterprise Linux (RHEL) для ядра реального времени. Тем не менее многие системные администраторы неверно истолковывают его основные концепции и фактическое рабочее поведение. В этой статье я опишу некоторые из его основных функций, отличия от стандартного ядра и шаги по установке.

Планировщик ЦП в реальном времени

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

Мы называем задержкой события время, которое проходит с момента возникновения события до момента его обслуживания. Есть два типа задержек, оказывающих влияние на производительность ОС реального времени.

Задержка прерывания относится к периоду времени от поступления прерывания в CPU до запуска процедуры обработки. Когда происходит событие, ОС должна сначала завершить выполняемую инструкцию и определить тип возникшего прерывания. Затем она должна сохранить состояние текущего процесса до обработки прерывания с помощью специальной процедуры, interrupt service routine (ISR).

Рис. 1 Задержка прерывания.
Время, необходимое диспетчеру планирования для остановки одного процесса и запуска другого, называется задержкой диспетчеризации. Предоставление задач реального времени с немедленным доступом к процессору требует, чтобы ОС реального времени минимизировали также и эту задержку. Наиболее эффективным методом поддержания низкой задержки отправки является предоставление ядер с приоритетным прерыванием.

Рис. 2 Задержка диспетчеризации.

Планировщик с учетом приоритетности процессов

Наиболее важной особенностью ОС реального времени — немедленно реагировать на критический процесс, требующий доступ к ресурсам CPU. В результате планировщик для операционной системы реального времени должен поддерживать алгоритм приоритетного прерывания. Такие алгоритмы назначают каждому процессу приоритет в зависимости от его степени важности. Если планировщик также поддерживает приоритетное прерывание, текущий процесс на CPU по запросу будет вытеснен в пользу более приоритетного процесса.

Рис. 3 Классификация планировщиков.

Существует несколько алгоритмов для планировщика в реальном времени.

Rate-Monotonic Scheduling — алгоритм со статическим приоритетом класса планирования. Статические приоритеты назначаются в соответствии с продолжительностью цикла задачи, вследствие чего более короткие циклы имеют более высокий приоритет исполнения. В худшем случае КПД загрузки центрального процессора ограничен следующей величиной.

При числе процессов n, стремящемся к бесконечности ряд будет сходиться к ln2 ≈ 0.693147.
Earliest-deadline-first (EDF) Scheduling динамически назначает приоритеты в соответствии с крайним сроком. Чем раньше крайний срок, тем выше приоритет и чем позже крайний срок, тем ниже приоритет. В отличие от RMS, планировщик EDF не требует, чтобы процессы были периодическими и постоянно запрашивали одно и то же количество процессорного времени на пакет. Единственное требование состоит в том, чтобы процесс объявлял свой крайний срок планировщику, когда он готов к запуску.

Рис. 4 Планировщик EDF.

На рисунке видим общий принцип работы планировщика. На точке 4 был замещён T1 и его место занял T2 так как его крайний срок наступал раньше, чем у T2. После отработки T3 планировщик вернулся к T1, который завершился на отметке 23.
POSIX real-time-scheduling. Стандарт POSIX.4 определяет три политики планирования. Каждый процесс имеет атрибут планирования, который может быть выставлен в одну из трех вариантов политики.

• SCHED_FIFO — политика упреждающего планирования с постоянным приоритетом, при которой процессы с одинаковым приоритетом обрабатываются в порядке «первым пришел — первым обслужен» (FIFO). Данная политика может иметь не менее 32 уровней приоритета.
• SCHED_RR — политика аналогична SCHED_FIFO, но использует метод временного среза (циклический перебор) для планирования процессов с одинаковыми приоритетами. Он также имеет 32 уровня приоритета.
• SCHED_OTHER — политика не определена и зависит от системы; может вести себя по-разному в разных реализациях.

Установка и использование RHEL Real Time

Для начала следует подключить репозиторий Red Hat Enterprise Linux для Real Time, и установить группу пакетов RT.

В составе RT идут эти компоненты:

• kernel-rt — ядро с функционалом реального времени;
• rt-setup — установка окружения Red Hat Enterprise Linux Real Time;
• rt-tests — утилиты тестирования функций RT;
• rt-eval — для оценки возможности применять RT на данной системе;

После установки RT и перезагрузки нужно убедиться, что загружено ядро kernel-rt.

Посмотрим на некоторые отличия kernel-rt от стандартного ядра.

• При высокой нагрузке происходит проверка приоритета задачи (1-99).
• Высокоприоритетным (99) задачам отдается предпочтение при доступе к ресурсам центрального процессора.
• Не задействует политику Completely Fair Scheduling (CFS).
• Использует политику SCHED_FIFO, либо же SCHED_RR.

Рис. 5 Сравнение kernet_rt со стандартным ядром.

На графике показан замер времени отклика из миллиона повторений для систем, использующих ядра RHEL Linux 7 и RHEL Real Time соответственно. Синие точки на этом графике представляют время отклика (в микросекундах) систем со стандартным ядром RHEL 7, а зеленые — RHEL 7 Real Time. Из графика видно, что особенность kernel-rt в гораздо меньшей дисперсии и, соответственно, в большей предсказуемости времени отклика системы.

Настройка и тестирование

После установки RT может потребоваться дополнительная настройка и доводка для достижения наиболее стабильных показателей времени отклика системы. Такие требования могут предъявить компании финансового, или телекоммуникационного сектора. Сама настройка — итеративный процесс и нужно запастись терпением в начале процесса. Вряд ли получится подкрутить пару переменных и понять, что достигнут наилучший результат из возможных.

Утилита hwlatdetect из пакета rt-tests покажет задержки, вызванные аппаратным и микропрограммным обеспечением, путем опроса источника тактовых импульсов и поиска непонятных пропусков.

В данном примере parameters указывает на задержку и способ обнаружения. Порог задержки по умолчанию был выставлен на 10 микросекунд (10 μs).

RT имеет также утилиту rteval для тестирования производительности системы в реальном времени под нагрузкой. Программа создаёт большую нагрузку на систему, используя планировщик SCHED_OTHER, а затем измеряет отклик в реальном времени на каждом из активных CPU. Цель в том, чтобы постоянно выполнялись различные задачи, такие как выделение / освобождение памяти, дисковый I/O, вычисления, копирование памяти и другие.

Каждый поток измерений берет временную метку, бездействует в течение некоторого интервала, а затем принимает другую временную метку после пробуждения. Задержка по результатам измерения равна t1 — (t0 + i) , где

• t1 — фактическое время измерения;
• t0 — теоретическое время пробуждения первой временной метки;
• i — интервал ожидания.

Отчет утилиты rteval выглядит так.

Использованные материалы

• Abraham Silberschatz, Peter Baer Galvin, Greg Gagne Operating System Concepts 9-th edition.
• What are the benefits of running the Red Hat Enterprise Linux for Real Time?
• Working with the real-time kernel for Red Hat Enterprise Linux
• Advanced tuning procedures to optimize latency in RHEL for Real Time

Источник