7.2 Linux и работа в реальном времени

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

▪Высокая задержка прерывания

▪Высокая задержка планировщика из-за того, что ядро по своей природе не имело поддержки вытеснения

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

▪Другие функции, такие как виртуальная память и системные вызовы, также делают Linux недетерминированным в его откликах.

Ключевым различием между любой операционной системой общего назначения, подобной Linux, и ОС жёсткого реального времени является детерминированное поведение во времени в RTOS всех служб ОС. Под детерминированным временем мы имеем в виду, что любая предполагаемая задержка или время, затраченное любой службой ОС, также должно быть ограничено. Говоря в математических терминах, вы должны иметь возможность выразить эти временные параметры с использованием алгебраической формулы без какой-либо переменной составляющей. Переменная составляющая вводит неопределённость, сценарий, неприемлемый для систем жёсткого реального времени.

Так как Linux в своей основе ОС общего назначения, требуются серьёзные изменения, чтобы получить приемлемое время отклика для всех служб ОС. Поэтому было сделано разделение: чтобы использовать Linux в системах жёсткого реального времени, были сделаны варианты Linux жёсткого реального времени, RTLinux и RTAI. С другой стороны, в ядро была добавлена поддержка для снижения задержек и улучшения времени отклика различных служб ОС, чтобы сделать его пригодным для требований мягкого реального времени.

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

▪Завершение I/O. Устройство вызывает прерывание. Это вызывает работу ISR (Interrupt Service Routine, Процедуру Обработки Прерываний) драйвера блочного устройства.

▪ISR проверяет очередь ожидания драйвера и находит задачу, ожидающую ввод/вывод. Затем вызывается одна из функций, предназначенных для пробуждения. Эта функция удаляет задачу из очереди ожидания и добавляет её в очередь выполнения планировщика.

▪Затем ядро, когда оно попадает в точку, где планирование разрешено, вызывает функцию schedule.

▪Наконец, schedule() находит следующего подходящего кандидата для работы. Контекст ядра переключается на нашу задачу, если она имеет достаточно высокий приоритет, чтобы быть запланированной.

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

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

▪Продолжительность работы ISR: время, необходимое обработчику прерывания для выполнения.

▪Задержка планировщика: задержка планировщика это количество времени, которое проходит между завершением процедуры прерывания и запуском функции планирования.

▪Продолжительность работы планировщика: это время, затраченное функцией планировщика, чтобы выбрать для запуска следующую задачу и переключить на неё контекст.

Теперь обсудим различные причины описанных выше задержек и способы их снижения, которые включены в ядро.