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 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.