Linux в реальном времени объяснил и сравнил с Xenomai и RTAI

В ELC Europe разработчик Linux для реального времени Ян Альтенберг рассказал о прогрессе RTL, сравнил его с Xenomai и RTAI и представил новые тесты.

Linux реального времени (RTL), форма основного Linux, включенная с помощью PREEMPT_RT, прошла большой путь за последнее десятилетие.
Около 80 процентов детерминированного патча PREEMPT_RT теперь доступно в основном ядре.
Тем не менее, сторонники самой мощной альтернативы одноядерному RTL в Linux - двухядерному Xenomai - продолжают претендовать на огромное превосходство в сниженной задержке.
В октябре на презентации Embedded Linux Conference Europe Ян Альтенберг опроверг эти утверждения, предложив обзор темы в реальном времени.


В ELCE Ян Альтенберг рассказывает об архитектуре PREEMPT_RT Linux в реальном времени

(щелкните изображение, чтобы увеличить)

Альтенберг из немецкой фирмы по разработке встраиваемых систем Linutronix не отрицает, что двухъядерные подходы, такие как Xenomai и RTAI (интерфейс приложений реального времени), обеспечивают меньшую задержку.
Тем не менее, он раскрывает новые тесты Linutronix, которые призваны показать, что различия не так велики, как заявлено, особенно в реальных сценариях.
Менее спорно, он утверждает, что РТЛ намного легче развиваться и поддерживать.

Прежде чем мы углубимся в вечную дискуссию о Xenomai и RTL, обратите внимание, что в октябре 2015 года лаборатория разработки Open Source Automation (OSADL) передала контроль над проектом RTL Linux Foundation, на котором размещается Linux.com.
Кроме того, Linutronix является ключевым участником проекта RTL и поддерживает его сопровождающего x86.

Развитие RTL является одной из нескольких причин, по которым Linux за последнее десятилетие похитил долю рынка у операционных систем реального времени (ОСРВ).
RTOS появляются чаще на микроконтроллерах, чем на процессорах приложений, и это проще сделать в режиме реального времени на специализированных устройствах, в которых отсутствуют передовые пользовательские ОС, такие как Linux.

Альтенберг начал свое выступление с разъяснения некоторых распространенных заблуждений о детерминированных схемах ядра в реальном времени (или в реальном времени).
«В реальном времени речь идет не о быстром исполнении или производительности», - сказал Альтенберг своей аудитории в ELCE.
«Это в основном о детерминизме и временных гарантиях.
В режиме реального времени вы гарантируете, что что-то будет выполнено в течение определенного периода времени.
Вы не хотите быть настолько быстрым, насколько это возможно, но так быстро, как указано.

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

По словам Альтенберга, требования к режиму реального времени включают детерминированные временные характеристики, приоритетное прерывание, наследование приоритетов и потолок приоритетов.
«Наиболее важным требованием является то, что задача с высоким приоритетом всегда должна иметь возможность вытеснить задачу с низким приоритетом».

Альтенберг настоятельно рекомендует не использовать термин «мягкое в реальном времени» для описания легких решений в реальном времени.
«Вы можете быть детерминированным или нет, но между ними нет ничего».

Двухъядерный в режиме реального времени

Двухъядерные схемы, такие как Xenomai и RTAI, развертывают микроядро, работающее параллельно с отдельным ядром Linux, в то время как одноядерные схемы, такие как RTL, делают Linux работоспособным в режиме реального времени.
«Благодаря двухъядерному Linux может получить некоторое время выполнения, когда приоритетные приложения реального времени не работают на микроядре», - сказал Альтенберг.
«Проблема в том, что кому-то нужно поддерживать микроядро и поддерживать его на новом оборудовании.
Это огромные усилия, и сообщества разработчиков не очень велики.
Кроме того, поскольку Linux не работает непосредственно на оборудовании, вам необходим уровень абстрагирования оборудования (HAL).
Имея две вещи для поддержки, вы обычно на шаг отстаете от основной разработки Linux ».


Ян Альтенберг описывает RTL (слева) и показывает архитектуру Xenomai

(нажмите на картинку, чтобы увеличить)

Проблема с RTL, и причина, по которой он появился так долго, состоит в том, что «для того, чтобы сделать Linux в реальном времени, вы должны в основном касаться каждого файла в ядре», сказал Альтенберг.
Тем не менее, большая часть этой работы уже выполнена и включена в основную линию, и разработчикам не нужно поддерживать микроядро или HAL.

Альтенберг продолжал объяснять различия между RTAI и Xenomai.
«С помощью RTAI вы пишете модуль ядра, который планируется микроядром.
Это похоже на разработку ядра - очень сложно разобраться с этим и трудно отладить ».

Разработка RTAI может быть еще более сложной, поскольку промышленные заказчики часто хотят включать закрытый исходный код вместе с кодом ядра GPL.
«Вы должны решить, какие части вы можете поместить в пользовательское пространство, а какие - в ядро, используя подходы в реальном времени», - сказал Альтенберг.

RTAI также поддерживает меньше аппаратных платформ, чем RTL, особенно помимо x86.
Двухъядерный Xenomai, который затмил RTAI как доминирующий двухъядерный подход, имеет более широкую поддержку ОС, чем RTAI.
Что еще более важно, он предлагает «правильное решение для работы в реальном времени в пространстве пользователя», сказал Альтенберг.
«Для этого они реализовали концепцию скинов - слой эмуляции для API различных RTOS, таких как POSIX.
Это позволяет вам повторно использовать подмножество существующего кода из некоторых RTOS ».

Однако с Xenomai вам все равно нужно поддерживать отдельное микроядро и HAL.
Ограниченные средства разработки являются еще одной проблемой.
«Как и в случае с RTAI, вы не можете использовать стандартную библиотеку C», - сказал Альтенберг.
«Вам нужны специальные инструменты и библиотеки.
Даже для POSIX вы должны ссылаться на скин POSIX, который намного сложнее ». Он добавил, что на любой из платформ трудно масштабировать микроядра от 8 до 16 процессоров для больших кластеров серверов, используемых в финансовых сервисах.

Спальные Спинлоки

Доминирующим одноядерным решением является RTL, основанное на PREEMPT.RT, которое было разработано Томасом Гляйкснером и Инго Мольнаром более десяти лет назад.
PREEMPT.RT обновляет блокирующие блокировки ядра «spinlock», чтобы максимизировать выгружаемые секции внутри ядра Linux.
(Первоначально PREEMPT.RT назывался патч Sleep Spinlocks.)

Вместо того чтобы запускать обработчики прерываний в контексте жесткого прерывания, PREEMPT.RT запускает их в потоках ядра.
«Когда приходит прерывание, вы не запускаете код обработчика прерывания», - сказал Альтенберг.
«Вы просто запускаете соответствующий поток ядра, который запускает обработчик.
Это имеет два преимущества: поток ядра становится прерываемым и отображается в списке процессов с идентификатором PID.
Таким образом, вы можете придавать низкий приоритет второстепенным прерываниям и более высокий приоритет важным задачам пользователя ».

Поскольку около 80 процентов PREEMPT.RT уже находится в основной сети, любой разработчик Linux может воспользоваться преимуществами компонентов ядра, созданных PREEMPT.RT, таких как таймеры, обработчики прерываний, инфраструктура трассировки и наследование приоритетов.
«Когда они сделали Linux в режиме реального времени, все стало приоритетным, поэтому мы обнаружили множество условий гонки и проблем с блокировками», - сказал Альтенберг.
«Мы исправили их и вернули обратно в основную ветку, чтобы улучшить стабильность Linux в целом».

Поскольку RTL - это, главным образом, основной Linux, «PREEMPT.RT широко распространен и имеет огромное сообщество», - сказал Альтенберг.
«Если вы пишете приложение в режиме реального времени, вам не нужно много знать о PREEMPT.RT.
Вам не нужны никакие специальные библиотеки или API, только стандартная библиотека C, драйвер Linux и приложение POSIX ».

Вам все еще нужно запустить патч для использования PREEMPT.RT, который обновляется в каждой второй версии Linux.
Однако в течение двух лет оставшиеся 20 процентов PREEMPT.RT должны перейти на Linux, так что вам «не понадобится патч».

Наконец, Альтенберг обнародовал результаты своих тестов латентности Xenomai против RTL.
«Есть много работ, в которых утверждается, что Xenomai и RTAI намного быстрее в задержке, чем PREEMPT.RT», - сказал Альтенберг.
«Но я понял, что большую часть времени PREEMPT.RT был плохо настроен.
Поэтому мы привлекли как эксперта Xenomai, так и эксперта PREEMPT.RT, и позволили им настраивать свои собственные платформы ».

По словам Альтенберга, Xenomai показала лучшие результаты в большинстве тестов и дала гораздо меньше дрожания, но различия не были такими большими, как превосходство задержки на 300–400%, заявленное некоторыми ускорителями Xenomai.
По его словам, когда выполнялись тесты для задач в пользовательском пространстве, которые, по словам Альтенберга, являются наиболее реальными и, следовательно, наиболее важными тестами, реакция в худшем случае составляла от 90 до 95 микросекунд для Xenomai и RTL / PREEMPT.RT.

Когда они изолировали один процессор в двойной системе Cortex-A9 для обработки рассматриваемого прерывания, что, по словам Альтенберга, является довольно распространенным явлением, PREEMPT.RT работал немного лучше, занимая около 80 микросекунд.
(Для более подробной информации, посмотрите видео о 33 минутах.)

Альтенберг признает, что его 12-часовой тест является абсолютным минимумом по сравнению с тестами OSADL, проводимыми два-три года, и что это «не математическое доказательство». В любом случае он полагает, что RTL заслуживает помех, учитывая его более простую разработку. процесс.
«По моему мнению, было бы несправедливо сравнивать полнофункциональную систему Linux с микроядром», - заключил он.

Для более подробной информации, смотрите полную презентацию ниже:

Введение в Realtime Linux video (ELCE 2016)

Эта статья защищена авторским правом © 2017 Linux.com и была первоначально опубликована здесь .
Он был воспроизведен этим сайтом с разрешения его владельца.
Пожалуйста, посетите Linux.com для получения последних новостей и статей о Linux и open source.