LINUX.ORG.RU
 
papochka

Представлен набор 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-ядра, ранее выпуск патчей существенно отставал, что было связано с большой трудоёмкостью процесса портирования и тестирования.

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


[#] Ответ на: комментарий от arsi 26.07.2011 9:32:06  

> говорят, что причина — удерживание блокировки прерываний (с рт-патчем) больше 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 никому не надо %)

***** ()
[#] Ответ на: комментарий от anonymous 26.07.2011 10:29:22  
arsi

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

**** ()
[#] Ответ на: комментарий от tailgunner 26.07.2011 10:46:51  
arsi

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

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

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

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

**** ()
[#] Ответ на: комментарий от arsi 26.07.2011 10:53:29  

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

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

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

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

> надо!!11

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

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

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

***** ()
[#] Ответ на: комментарий от arsi 26.07.2011 10:41:05  

>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 26.07.2011 10:47:58  

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

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

anonymous ()
[#] Ответ на: комментарий от anonymous 26.07.2011 11:18:43  
arsi

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

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

**** ()
[#] Ответ на: комментарий от arsi 26.07.2011 11:33:25  

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

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

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


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

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


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

anonymous ()
[#] Ответ на: комментарий от anonymous 26.07.2011 11:42:53  
arsi

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

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

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

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

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

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

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

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

**** ()
[#] Ответ на: комментарий от arsi 26.07.2011 12:00:25  

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

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

>сам придумал


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

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


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

anonymous ()
[#] Ответ на: комментарий от arsi 26.07.2011 12:00:25  

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

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

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

** ()
[#]  
linux

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

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

* ()
[#] Ответ на: комментарий от linux 26.07.2011 12:22:12  

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

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

anonymous ()
[#] Ответ на: комментарий от linux 26.07.2011 12:22:12  
devl547

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

//Lenovo Y550p

**** ()
[#] Ответ на: комментарий от arsi 26.07.2011 12:00:25  

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

* ()
[#] Ответ на: комментарий от ZenitharChampion 25.07.2011 16:06:07  
adepto

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

* ()
[#] Ответ на: комментарий от GHhost 26.07.2011 13:09:22  
arsi

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

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

**** ()
[#] Ответ на: комментарий от arsi 26.07.2011 13:35:04  

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

* ()
[#] Ответ на: комментарий от GHhost 26.07.2011 15:47:43  
arsi

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

**** ()
[#] Ответ на: комментарий от arsi 26.07.2011 16:19:51  

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

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

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

anonymous ()
[#] Ответ на: комментарий от anonymous 26.07.2011 16:35:44  
arsi

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

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

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

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

**** ()
[#] Ответ на: комментарий от arsi 26.07.2011 16:43:21  

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

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

anonymous ()
[#] Ответ на: комментарий от anonymous 26.07.2011 17:17:00  

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

anonymous ()
[#]  

супер

***** ()
[#] Ответ на: комментарий от arsi 26.07.2011 12:00:25  

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

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

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

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

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

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

***** ()
[#] Ответ на: комментарий от AVL2 27.07.2011 14:21:11  

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

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

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

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

***** ()
[#] Ответ на: комментарий от tailgunner 27.07.2011 14:46:17  

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

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

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

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

***** ()
[#] Ответ на: комментарий от AVL2 27.07.2011 14:52:12  

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

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

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

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

Глупости.

***** ()
[#] Ответ на: комментарий от tailgunner 27.07.2011 15:40:36  

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

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

***** ()
[#] Ответ на: комментарий от AVL2 27.07.2011 16:46:32  

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

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

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

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

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

***** ()
[#] Ответ на: комментарий от tailgunner 27.07.2011 16:50:53  

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

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

* ()
[#] Ответ на: комментарий от GHhost 27.07.2011 23:20:03  

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

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

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

***** ()
[#] Ответ на: комментарий от tailgunner 27.07.2011 23:23:37  

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

* ()
[#]  

тока что -rt4 is out

* ()
[#] Ответ на: комментарий от tailgunner 27.07.2011 16:50:53  

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

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

***** ()
[#] Ответ на: комментарий от GHhost 28.07.2011 0:31:32  
devl547

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

**** ()
[#] Ответ на: комментарий от devl547 28.07.2011 14:08:52  
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 28.07.2011 14:17:28  

а что ты хотел, это даже не rc.

* ()
[#] Ответ на: комментарий от GHhost 28.07.2011 19:21:41  
devl547

>это даже не rc.

linux-3.0-rt4. Так бы сразу и писали, что -SSZB-unstable-prealpha

**** ()
[#]  
havelite

как обычно гоняется за qnx

* ()