LINUX.ORG.RU

Представлен набор RT-патчей для ядра Linux 3.0

 ,


0

1

Томас Глейкснер (Thomas Gleixner), основной разработчик и мейнтейнер RT-ветки ядра Linux, сообщил о выпуске третьей верcии набора патчей с реализацией режима реального времени (Realtime-Preempt", PREEMPT_RT или "-rt") для ядра Linux 3.0. Ядро "-rt" с реализацией жёсткого режима реального времени используется в real-time редакциях промышленных Linux дистрибутивов MontaVista, Red Hat и Novell. Это первое крупное обновление RT-Linux за последние несколько лет, знаменующее уход от ядра версии 2.6.33, которое использовалось в качестве базы для RT-ветки несколько лет подряд.

В письме, отправленном в список рассылки Linux-ядра, Томас Глейкснер отмечает существенное отличие новой версии патчей от предыдущих. Логика работы многих подсистем была кардинально переработана, код стал намного чище и проще для анализа, общий размер патчей сократился более чем в два раза. Теперь код затрагивает гораздо меньше подсистем и структур данных ядра, что, по мнению автора, позволит ускорить процесс его включения в основную ветку. 223 подготовленных в рамках проекта патча, затрагивающих 374 файла разбиты на 4 группы, из которых одна группа устраняет недоработки уже находящихся в ядре подсистем, одна группа уже отправлена для включения в состав основного ядра, одна признана готовой для отправки заявки на включение в состав ядра и одна требует доработки и проверки. Для сравнения, для ветки 2.6.33 было подготовлено 462 патча, затрагивающих 690 файлов.

Ядро с наложенными патчами было протестировано на платформах x86 и x86_64, а также на ARM, MIPS и PowerPC и, по словам Thomas Gleixner оказалось «удивительно стабильным» (amazinlgy stable). Событие знаменательно тем, что это первый случай когда RT-патчи адаптированы для последней актуальной версии Linux-ядра, ранее выпуск патчей существенно отставал, что было связано с большой трудоёмкостью процесса портирования и тестирования.

>>> Подробности



Проверено: post-factum ()
Последнее исправление: post-factum (всего исправлений: 3)
Ответ на: комментарий от arsi

> говорят, что причина — удерживание блокировки прерываний (с рт-патчем) больше 300мкс.

http://lkml.org/lkml/2007/12/19/139 и дальше по ветке.

Q: preempt-rt can disable interrupts for 300 us?

A: I am not sure if it really is an interrupt lock that long

Так что даже автор багрепорта не уверен, что реально есть задержка в 300мкс. Скорее, дело в том, что -rt на Atmel никому не надо %)

tailgunner
()
Ответ на: комментарий от anonymous

и да, речь о DBGU. USARTы могут сразу по DMA писать, зачем им фифо. и заканчивай уже переводить стрелки на атмел: при preempt данные не теряются, при preempt-rt — как минимум каждый второй байт теряется (на 115200).

arsi
()
Ответ на: комментарий от tailgunner

> Так что даже автор багрепорта не уверен, что реально есть задержка в 300мкс.

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

> Скорее, дело в том, что -rt на Atmel никому не надо %)

надо!!11 но не такой -рт :)

arsi
()
Ответ на: комментарий от arsi

>> Так что даже автор багрепорта не уверен, что реально есть задержка в 300мкс.

ага, они там так и не пришли в окончательному выводу, кто виноват и что делать.

Но выразили свою неуверенность в существовании блокировки прерывания на 300мкс.

Скорее, дело в том, что -rt на Atmel никому не надо %)

надо!!11

Был бы надо - нашли бы затык.

но не такой -рт :)

Сделай свой %)

tailgunner
()
Ответ на: комментарий от arsi

8250. историю помнить надо :)

Так мне-то зачем, это атмеловским горе-инженерам нужно помнить:

With the introduction of multitasking operating systems on PC hardware, such as OS/2, Windows NT or various flavours of UNIX, the short time available to serve character-by-character interrupt requests became a problem, therefore the IBM PS/2 serial ports introduced the 16550(A) UARTs that had a built-in 16 byte FIFO or buffer memory to collect incoming characters.

anonymous
()
Ответ на: комментарий от arsi

>и да, речь о DBGU. USARTы могут сразу по DMA писать, зачем им фифо.

Ну так и повесь отладочную консоль на обычный uart. И да - при использовании pdc кольцевой буфер - это и есть аппаратный fifo.

anonymous
()
Ответ на: комментарий от anonymous

> Ну так и повесь отладочную консоль на обычный uart.

низя, заняты. и это не решит проблемы тормозного preempt-rt. ну будет он пропускать прерывания не от DBGU, а от генератора временной метки, например, и что? нафиг нужен хард рилтайм, не способный выполнять свои задачи — гарантированно обработать данные за промежуток времени, когда эти данные ещё актуальны?

arsi
()
Ответ на: комментарий от arsi

>низя, заняты.

Там их 6 штук, ты что-то наверно путаешь :)

и это не решит проблемы тормозного preempt-rt.


RTOS всегда менее эффективны чем general purpose OS

ну будет он пропускать прерывания не от DBGU, а от генератора временной метки, например, и что? нафиг нужен хард рилтайм, не способный выполнять свои задачи — гарантированно обработать данные за промежуток времени, когда эти данные ещё актуальны?


Я не понял - у тебя проблемы с UART или с головой ? какие прерывания пропускать ? их обработка откладывается, если тебе не хватает скорости выбранного тобой процессора - это не проблема RTOS, там есть куча тестов на worst latensy.

anonymous
()
Ответ на: комментарий от anonymous

> Там их 6 штук, ты что-то наверно путаешь :)

внезапно, атмел выпускает не один чип на арм. и ещё один сюрприз: я не с отладочной платой работаю, а с готовым устройством, где «лишние» порты элементарно не выведены.

> RTOS всегда менее эффективны чем general purpose OS

сам придумал или одноклассник рассказал?

> Я не понял - у тебя проблемы с UART или с головой ?

у меня нет проблем.

> их обработка откладывается, если тебе не хватает скорости выбранного тобой процессора - это не проблема RTOS

preempt-rt и preempt запускались на одном и том же чипе, с одинаковыми настройками приоритетов прерываний (у DBGU был самый высокий приоритет). о какой внезапной нехватке скорости ты говоришь?

arsi
()
Ответ на: комментарий от arsi

>и ещё один сюрприз: я не с отладочной платой работаю, а с готовым устройством

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

сам придумал


сходи уже почитай хоть что-нибуть про ОС

preempt-rt и preempt запускались на одном и том же чипе, с одинаковыми настройками приоритетов прерываний (у DBGU был самый высокий приоритет). о какой внезапной нехватке скорости ты говоришь?


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

anonymous
()
Ответ на: комментарий от arsi

>> RTOS всегда менее эффективны чем general purpose OS

сам придумал или одноклассник рассказал?

По определению же gpOS заточена для оптимального распределения ресурсов, а RTOS для гарантированного ответа на внешние события. А что, есть примеры RTOS, более производительных чем GPOS?

AptGet
()

только что просмотрел патч, похоже что 1) он ни чего не делает для прироста производительности 2) основной акцент на 64битную АМД архитектуру

и вообще, че вы шумите, посмотрите исходник патча, нет тут темы для шума

linux
()
Ответ на: комментарий от linux

>1) он ни чего не делает для прироста производительности

он и не должен делать что-либо для прироста производительности, скорее наоборот.

anonymous
()
Ответ на: комментарий от linux

Я с утра сравнил обычный 3.0 из гита и rt3.
Разницы в отклике не заметил, rt3 стала чуть медленнее грузиться и более падучая (повисла у меня 3 раза за час работы - просто при старте, при компиляции вебкита и при игре в Nexuiz)

//Lenovo Y550p

devl547 👍👍
()
Ответ на: комментарий от ZenitharChampion

ZenitharChampion> В убунте оно было. Зачем убрали не знаю.
Свежие патчи кончались :)

adepto
()
Ответ на: комментарий от GHhost

> а стабильную -rt ветку не пробовал там запустить?

хм… кстати да, пробовал когда-то давно, с 2.6.33.х, емнип. не помню, чтобы с ним были какие-то проблемы, разве что отсутствие одного нужного драйвера, из-за чего решил временно пожертвовать -rt и взять более свежее ядро (емнип, .37).
// но rt-патча я к нему так и не дождался. поэтому и набросился на 3.0, как только о -rt1 к нему услышал…

arsi
()
Ответ на: комментарий от arsi

ну если в .33 работало то тут получается регрессия, учитывая что 3.0 тока тока запилили и косяков там еще тьма пиши багрепорт - думаю зафиксятю

GHhost
()
Ответ на: комментарий от GHhost

соберу .33, проверю. я его и тогда не сильно тестил. если глюк проявляться не будет… бекпортирую на него недостающий драйвер :)

arsi
()
Ответ на: комментарий от arsi

>бекпортирую на него недостающий драйвер :)

Ты видимо даже не в курсе о существовании этого сайта http://www.at91.com/linux4sam/bin/view/Linux4SAM/LinuxKernel

скажу тебе по секрету - там драйверов намного больше чем в ванильном ядре :)

anonymous
()
Ответ на: комментарий от anonymous

> Ты видимо даже не в курсе о существовании этого сайта

ты, видимо, упоротый.

> скажу тебе по секрету - там драйверов намного больше чем в ванильном ядре :)

скажу тебе по секрету — нет там необходимого драйвера.

arsi
()
Ответ на: комментарий от arsi

>скажу тебе по секрету — нет там необходимого драйвера.

Какой драйвер тебе нужен и о каком из at91 процессоров речь ?

anonymous
()
Ответ на: комментарий от anonymous

Хотя я совсем забыл что это может может внешнее устройство на usb, spi i2c etc :)

anonymous
()
Ответ на: комментарий от arsi

>> RTOS всегда менее эффективны чем general purpose OS

сам придумал или одноклассник рассказал?

есть возражения?

их обработка откладывается, если тебе не хватает скорости выбранного тобой процессора - это не проблема RTOS

preempt-rt и preempt запускались на одном и том же чипе, с одинаковыми настройками приоритетов прерываний (у DBGU был самый высокий приоритет). о какой внезапной нехватке скорости ты говоришь?

rtos не обязана работать быстро. Она обязана не превышать некий предел задержки. Величина этого предела зависит от аппаратки и эффективности самой ОС.

AVL2
()
Ответ на: комментарий от AVL2

> rtos не обязана работать быстро

Вообще-то обязана. Одна из пузомерок^Wметрик, по которым оценивается RTOS - это величина задержки обработки прерывания (то же про задержки планирования). И да, для того, чтобы эти величины были низкими, диспетчер прерываний и планировщик должны работать быстро.

Она обязана не превышать некий предел задержки.

Ну да, стандартный Linux - это RTOS, просто у нее величина interrupt latency - секунда %)

tailgunner
()
Ответ на: комментарий от tailgunner

>Вообще-то обязана. Одна из пузомерок^Wметрик, по которым оценивается RTOS - это величина задержки обработки прерывания (то же про задержки планирования). И да, для того, чтобы эти величины были низкими, диспетчер прерываний и планировщик должны работать быстро.

Это при сравнение двух RTOS. А здесь сравнивали RTOS и универсальную ОС.

Ну да, стандартный Linux - это RTOS, просто у нее величина interrupt latency - секунда %)

Нет. Стандартный Linux это не RTOS, потому что у него величина максимальная interrupt latency в бесконечности.

AVL2
()
Ответ на: комментарий от AVL2

>> Одна из пузомерок^Wметрик, по которым оценивается RTOS - это величина задержки обработки прерывания

А здесь сравнивали RTOS и универсальную ОС.

ИЧСХ, их сравнивали как раз по interrupt latency.

что у него величина максимальная interrupt latency в бесконечности.

Глупости.

tailgunner
()
Ответ на: комментарий от tailgunner

>ИЧСХ, их сравнивали как раз по interrupt latency.

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

AVL2
()
Ответ на: комментарий от AVL2

>> ИЧСХ, их сравнивали как раз по interrupt latency.

и вполне логично, что ядро без RT отзывается в среднем быстрее.

Всегда быстрее. Но это просто баг в -rt

Так должно быть.

В общем-то, нет. Даже с -rt, драйвер должен успевать обслуживать прерывание.

tailgunner
()
Ответ на: комментарий от tailgunner

>В общем-то, нет. Даже с -rt, драйвер должен успевать обслуживать прерывание.

далеко не факт, очень легко и не принужденно может положить на это обслуживание.

GHhost
()
Ответ на: комментарий от GHhost

>> В общем-то, нет. Даже с -rt, драйвер должен успевать обслуживать прерывание.

далеко не факт, очень легко и не принужденно может положить на это обслуживание.

На нагруженной системе - может быть (если нить обработчика прерывания не сконфигурирована соотвественно). Но, судя по обсуждению, это не тот случай.

tailgunner
()
Ответ на: комментарий от tailgunner

ну да, я просто про то что не обязательно должен, зависит он настроек и нагрузки.

GHhost
()
Ответ на: комментарий от tailgunner

>В общем-то, нет. Даже с -rt, драйвер должен успевать обслуживать прерывание.

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

AVL2
()
Ответ на: комментарий от GHhost

надо бы обновиться.. а то rt3 виснуть у меня пытается (на ночь оставил компилять апдейты в генте - повисло со 100% загрузкой процессора и хорошо так прогрело ноут)

devl547 👍👍
()
Ответ на: комментарий от devl547

The list of disabled config option is now:
- CONFIG_HIGHMEM [ see the mess it created in 33-rt ]
- CONFIG_RCU_BOOST [ weird crashes reported, no idea what's wrong. Paul ?? ]
- CONFIG_RT_GROUP_SCHED [ brings the complete machine to stall. Peter ?? ]
- CONFIG_NOHZ [ softirq pending warnings and yet undebugged stalls ]
- CONFIG_TRANSPARENT_HUGEPAGE [ compound bit spin lock ]

//в общем, в лес его. буду сидеть на git-kernel и не страдать фигней с корявыми патчами.

devl547 👍👍
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.