Операционная система реального времени необходима, когда к работе процессора или потоку данных предъявляются жесткие временные требования. Таким образом она часто выполняет роль блока управления в специальных устройствах. Проведение научных экспериментов, приложения визуализации в медицине, промышленные устройства управления являются системами реального времени. Механизмы впрыска топлива автомобильных двигателей, контроллеры бытовой и военной техники также являются системами реального времени.
При этом разные события имеют различные временные требования. Например, требование к задержке для антиблокировочной тормозной системы может составлять от 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, который завершился на отметке 21. - 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.
[root@server ~]# subscription-manager repos --enable rhel-8-for-x86_64-rt-rpms
[root@server ~]# yum groupinstall RTВ составе RT идут эти компоненты:
- kernel-rt — ядро с функционалом реального времени;
- rt-setup — установка окружения Red Hat Enterprise Linux Real Time;
- rt-tests — утилиты тестирования функций RT;
- rt-eval — для оценки возможности применять RT на данной системе;
После установки RT и перезагрузки нужно убедиться, что загружено ядро kernel-rt.
[root@server ~]# uname -a
Linux rt-server.example.com 4.18.0-80.rt9.138.el8.x86_64 …Посмотрим на некоторые отличия 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 покажет задержки, вызванные аппаратным и микропрограммным обеспечением, путем опроса источника тактовых импульсов и поиска непонятных пропусков.
[root@server ~]# hwlatdetect --duration=60s
hwlatdetect: test duration 60 seconds
detector: tracer
parameters:
Latency threshold: 10us
Sample window: 1000000us
Sample width: 500000us
Non-sampling period: 500000us
Output File: None
Starting test
test finished
Max Latency: Below threshold
Samples recorded: 0
Samples exceeding threshold: 0В данном примере parameters указывает на задержку и способ обнаружения. Порог задержки по умолчанию был выставлен на 10 микросекунд (10 μs).
RT имеет также утилиту rteval для тестирования производительности системы в реальном времени под нагрузкой. Программа создаёт большую нагрузку на систему, используя планировщик SCHED_OTHER, а затем измеряет отклик в реальном времени на каждом из активных CPU. Цель в том, чтобы постоянно выполнялись различные задачи, такие как выделение / освобождение памяти, дисковый I/O, вычисления, копирование памяти и другие.
Каждый поток измерений берет временную метку, бездействует в течение некоторого интервала, а затем принимает другую временную метку после пробуждения. Задержка по результатам измерения равна
t1 - (t0 + i), где- t1 — фактическое время измерения;
- t0 — теоретическое время пробуждения первой временной метки;
- i — интервал ожидания.
Отчет утилиты rteval выглядит так.
System:
Statistics:
Samples: 1440463955
Mean: 4.40624790712us
Median: 0.0us
Mode: 4us
Range: 54us
Min: 2us
Max: 56us
Mean Absolute Dev: 1.0776661507us
Std.dev: 1.81821060672us
CPU core 0 Priority: 95
Statistics:
Samples: 36011847
Mean: 5.46434910711us
Median: 4us
Mode: 4us
Range: 38us
Min: 2us
Max: 40us
Mean Absolute Dev: 2.13785341159us
Std.dev: 3.50155558554us
Использованные материалы
- 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
