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, который завершился на отметке 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 -aLinux 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=60shwlatdetect:  test duration 60 secondsdetector: tracerparameters:Latency threshold: 10usSample window:     1000000usSample width:      500000usNon-sampling period:  500000usOutput File:       NoneStarting testtest finishedMax Latency: Below thresholdSamples recorded: 0Samples exceeding threshold: 0

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

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

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

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

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

System:Statistics:Samples:           1440463955Mean:              4.40624790712usMedian:            0.0usMode:              4usRange:             54usMin:               2usMax:               56usMean Absolute Dev: 1.0776661507usStd.dev:           1.81821060672usCPU core 0       Priority: 95Statistics:Samples:           36011847Mean:              5.46434910711usMedian:            4usMode:              4usRange:             38usMin:               2usMax:               40usMean Absolute Dev: 2.13785341159usStd.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