Как в режиме реального времени Linux 2.6?

Question

Я планирую перевести мой продукт из ОСРВ на встроенный Linux. У меня не так много требований в реальном времени, и несколько моих требований к RT составляют порядка 10 секунд миллисекунд.

Может кто-нибудь указать мне ссылку, которая скажет мне, как в реальном времени текущая версия Linux?

Есть ли еще какие-либо проблемы с переходом на коммерческую ОСРВ на Linux?

Answer 1

Большинство ответов вы можете получить в Linux реального времени вики и FAQ

Каковы возможности реального времени стандартного ядра Linux 2.6?

Традиционно ядро ​​Linux позволяет только одному процессу вытеснять другой только при определенных обстоятельствах:

• Когда процессор работает, код режима пользователя
• Когда код ядра возвращается из системного вызова или прерывания обратно в пространство пользователя
• Когда код ядра блокирует мьютекс или явно передает управление другому процессу

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

Параметр конфигурации Linux 2.6 CONFIG_PREEMPT_VOLUNTARY вводит проверки для наиболее распространенных причин длительных задержек, так что ядро ​​может добровольно передавать управление задаче с более высоким приоритетом, ожидающей выполнения. Это может быть полезно, но, хотя оно уменьшает количество длительных задержек (от сотен миллисекунд до потенциально секунд или более), оно не устраняет их. Однако в отличие от CONFIG_PREEMPT (обсуждается ниже), CONFIG_PREEMPT_VOLUNTARY оказывает гораздо меньшее влияние на общую пропускную способность системы. (Как всегда, существует классический компромисс между пропускной способностью - общей эффективностью системы - и задержкой. С более быстрыми процессорами современных систем часто имеет смысл компенсировать пропускную способность для более низких задержек, но для сервера Системы классов, которым не требуются гарантии минимальной задержки, вполне могут предпочесть использовать либо CONFIG_PREEMPT_VOLUNTARY, либо придерживаться традиционного не выгружаемого дизайна ядра.)

Ядро Linux 2.6 имеет дополнительную опцию конфигурации, CONFIG_PREEMPT, которая заставляет весь код ядра вне защищенных от спин-блокировок областей и обработчиков прерываний иметь право на недобровольное вытеснение потоками ядра с более высоким приоритетом. С этой опцией задержка в худшем случае падает до (около) миллисекунд с одной цифрой, хотя некоторые драйверы устройств могут иметь обработчики прерываний, которые будут вводить задержку намного хуже, чем эта. Если для приложения Linux реального времени требуются задержки, меньшие, чем однозначные миллисекунды, настоятельно рекомендуется использовать патч CONFIG_PREEMPT_RT.

У них также есть список "Gotcha's", как вы их называли в FAQ.

Что важно держать в ум при написании в реальном времени приложения

Забота о следующем во время начальная фаза запуска:

• Вызовите mlockall () как можно скорее из main ().
• Создайте все потоки во время запуска приложения и коснитесь каждой страницы всего стека каждого потока. Никогда не запускайте потоки динамически во время RT show, это разрушит поведение RT.
• Никогда не используйте системные вызовы, которые, как известно, генерируют сбои страниц, такие как Еореп (). (Открытие файлов делает Системный вызов mmap (), который генерирует страница неисправности).
• Если вы используете «глобальные переменные времени компиляции» и / или «глобальные переменные времени компиляции» arrays ', затем используйте mlockall () для предотвратить сбои страниц при доступе их.

больше информации: HOWTO: Создание RT-приложение

У них также есть большая страница публикаций , которую вы можете оформить.

Answer 2

Вы смотрели на Xenomai ? Это позволит вам запускать процессы «жесткого реального времени» над Linux, но в то же время предоставит вам доступ к обычным API-интерфейсам Linux для всех нужд не в реальном времени.

Answer 3

Существует два принципиально разных подхода к реализации возможностей реального времени в Linux.

1) Патч для существующего ядра с такими вещами, как патчи rt-preempt. Это в конечном итоге приведет к полностью вытесняющему ядру

2) Двухъядерный подход (например, xenomai, RTLinux, RTAI, ...)

Есть много ошибок, переходящих с ОСРВ на Linux.

Может, тебе не нужно в реальном времени?

Я говорю о Linux реального времени в моем обучении: http://www.reliableembeddedsystems.com/embedded-systems_7.html

Answer 4

Ответ, вероятно, "достаточно хорош".

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

Stock Linux 2.6 имеет несколько функций, подходящих для задач с низкой задержкой - в основном это:

• Политика планирования
• Блокировка памяти

Предполагается, что вы используете одноядерный компьютер, если у вас есть только одна задача, которая установила свою политику планирования на SCHED_FIFO или SCHED_RR (не важно, какая у вас только одна задача), И заблокировала всю ее память в случае с mlockall (), он будет запланирован, как только он будет готов к запуску.

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

Полагаю, "попробуй и посмотри" - это хороший ответ, но в твоем случае это, вероятно, довольно сложно (и может потребовать написания драйверов устройств и т. Д.).

Посмотрите на документ для sched_setscheduler для некоторой хорошей информации.