LINUX.ORG.RU

Релиз стабильной версии realtime-ядра Linux 2.6.34-rt

 , , ,


0

0

Состоялся релиз стабильной версии ядра Linux, модифицированного для использования в системах реального времени. Это ядро используется в промышленных дистрибутивах MontaVista, Red Hat и Novell.

На данный момент ядро -rt содержит около пятисот патчей, накладываемых поверх основного ядра. С момента выхода 2.6.33-rt было внесено более десяти тысяч коммитов. Интересен подход к проблеме тестирования, применённый в процессе подготовки 2.6.34-rt: все десять тысяч коммитов были разбиты на 400 групп, в среднем по 25 патчей в каждом. Далее группы поочерёдно применялись к ядру 2.6.33-rt и тестировались на предмет рассогласований с основными пятьюстами патчами.

Также заслуживает внимания факт постоянного уменьшения количества патчей в ядре -rt в силу перетекания их в основное ядро. Интеграция всех патчей проекта PREEMPT_RT, который и занимается выпуском ядер -rt, может завершиться к концу текущего года или в начале следующего. Вышеописанный метод слияния патчей потребовал всего около двух месяцев на переход от 2.6.33 к 2.6.34. Поэтому, при сохранении таких темпов работы, для интеграции патчей реального времени в ядро 2.6.38 потребуется около восьми месяцев.

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



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

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

Устоявшаяся, ещё в начале 90-х терминология однозначно определяет сабжевый тип многозадачности как «корпоративная многозадачность».

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

CTAPK> Ага, звизди больше.

Шо? Тут уже писали и ссылку давали на ответ разработчиков по поводу 12309, где они это и написали.

Quasar ★★★★★
()
Ответ на: комментарий от Zonzen

Zonzen> Устоявшаяся, ещё в начале 90-х терминология однозначно определяет сабжевый тип многозадачности как «корпоративная многозадачность».

Литуратуту 90-х я читал. И там всегда и везде было «Кооперативная многозадачность».

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

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

CTAPK
() автор топика
Ответ на: комментарий от Quasar

мгновенной реакции.


реакции за не более чем определённое указанное/( а в быту- ещё и измеренное) время.

и вообще, согласно теории относительности скорость распространения причинно следственных связей конечна...

Anonymous ★★★★★
()
Ответ на: комментарий от Quasar

>Литуратуту 90-х я читал.

В «литуратуте» оно конечно так!

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

>Свой «корпоратив» можешь поглотить задним проходом.

Не хочешь огрести в оффлайне, не веди себя как тупой скот в онлайне.

Zonzen
()

господа, для чего оно нужно вообще реально? вот на домашней машине для чего-нибудь пригодится?

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

> Какая прелесть. Корпоративная многозадачность. Windows 3.1 == true realtime operation system!

Не тру, но гораздо более приближенная к RTOS, чем Linux.

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

> Какая прелесть. Корпоративная многозадачность. Windows 3.1 == true realtime operation system!

Если процесс не отдал время явным образом, а его у него внезапно отобрали --- он не может быть rt. Не догадывались?

sv75 ★★★★★
()
Ответ на: комментарий от bolmer

> Не тру, но гораздо более приближенная к RTOS, чем Linux.

В Линукс есть такая же дисциплина обслуживания, ага.

sv75 ★★★★★
()
Ответ на: комментарий от CTAPK

Это советский CS. Там всё такое. Корпоративы, аутентификация, потоки (threads).

sv75 ★★★★★
()
Ответ на: комментарий от nbw

> Чаще всего проявляется при свопе

Чаще --- может быть, но «только» --- не верно.

sv75 ★★★★★
()
Ответ на: комментарий от CTAPK

да у тебя прям просто лаборатория по отлову глюков...

megabaks ★★★★
()
Ответ на: комментарий от sv75

>Возможно. К счастью, сейчас 2010-ые на дворе.

Да ради бога, называйте как угодно, то что я написал для умного достаточно. Здесь вроде пытаются РТ обсуждать, который 40 лет назад обсосали со всех сторон, вроде бы открой книжку и почитай, так нет же дискутируют люди, чем очень доставляют.

А 2010-е сейчас к сожалению, а не к счастью. Мы живём не в стране а на территории, почувствуйте разницу.

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

oomkiller не обязвтелен
при жёстком своппинге до него дело очень редко доходит
хорош поднимать этот вопрос -повторяю - дело не в самом своппинге как таковом

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

у Вас тоже 12309 отсутствует на дж/генте? у меня на резервном винте gentoo развёрнута (тоже 686) - никаких фризов нету (ядро gentoo-sources обычное с 1000HZ только)

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

> е тру, но гораздо более приближенная к RTOS, чем Linux.

Это не в ней случайно одно приложение может захавать все ресурсы и остальные ничего не получат? Это скорее антиреалтайм.

cvs-255 ★★★★★
()
Ответ на: комментарий от sv75

> Если процесс не отдал время явным образом, а его у него внезапно отобрали --- он не может быть rt

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

cvs-255 ★★★★★
()
Ответ на: комментарий от cvs-255

> Это не в ней случайно одно приложение может захавать все ресурсы и остальные ничего не получат? Это скорее антиреалтайм.

В realtime программа с соотвествующими полномочиями может забрать ресурсы и никому их не отдавать, пока не сочтет нужным. Заметь фразу «с соответствующими полномочиями».

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

> В realtime программа с соотвествующими полномочиями может забрать ресурсы и никому их не отдавать, пока не сочтет нужным. Заметь фразу «с соответствующими полномочиями».

Читаем что такое реалтайм. Он не имеет никакого отношения к проценту выдаваемых ресурсов.

cvs-255 ★★★★★
()
Ответ на: комментарий от cvs-255

> Читаем что такое реалтайм.

Читайте внимательно.

Он не имеет никакого отношения к проценту выдаваемых ресурсов.

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

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

> Только абстрактные реалтайм-задачи в вакууме не потребляют ресурсов.

А никто и не говорит, что ресурсы не выдаются. Вы путаете понятия «ос, в которой процессам выдается максимум ресурсов» и «ос реального времени».

cvs-255 ★★★★★
()
Ответ на: комментарий от cvs-255

> Вы путаете понятия «ос, в которой процессам выдается максимум ресурсов» и «ос реального времени».

Я пока что вообще не употреблял термин «ОС». И нет, я не путаю приведенные тобой термины. Кстати, твой первый термин вообще какой-то странный - любая ОС отдает максимум ресурсов процессам; а вот RTOS отдает ресурсы в первую очередь RT-процессам.

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

ну у меня его вообще поймать будет очень сложно
ибо кое-что поправил в ядре + далеко не дефолтные приоритеты у софта (в том числе на ввод-вывод)

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

> а вот RTOS отдает ресурсы в первую очередь RT-процессам.

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

cvs-255 ★★★★★
()
Ответ на: комментарий от cvs-255

>> а вот RTOS отдает ресурсы в первую очередь RT-процессам.

Нет.

Да.

Она гарантирует отклик за фиксированное время.

Это не противоречит моим словам. Выделение врменеи RT-процессам - один из способов гарантии отклика.

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

> Выделение врменеи RT-процессам - один из способов гарантии отклика

Зато это почти гарантия, что если один из этих процессов призадумается, то другим придется долго ждать. А это недопустимо.

cvs-255 ★★★★★
()
Ответ на: комментарий от cvs-255

Приведу пример: есть система управления 10 станками на конвеере. Каждый станок должен захватить деталь, обработать ее и опустить. Но в некий момент на одном из станков что-то происходит и деталь не отпускается. Описанная вами система будет ждать, пока он отпустит деталь, не останавливая остальные станки и конвеер. В то время как система реального времени по истечении стандартного времени скажет, что произошла ошибка, остановит конвеер и пошлет сигнал оператору о сбое.

cvs-255 ★★★★★
()
Ответ на: комментарий от cvs-255

> если один из этих процессов призадумается, то другим придется долго ждать.

Да.

А это недопустимо.

Это не только допустимо, это сама суть realtime (если не брать вещи вроде EDF, хотя... и для них тоже).

Почитай о SCHED_FIFO, да и о SCHED_RR.

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

Почитайте хотя бы про класс планирования процессов rt в линуксе. Потом напишите в lkml, что там дураки сидят.

1. Процесс возиться не «долго», а сколько надо. Если он возиться дольше требуемого времени отклика --- это плохо и процесс надо переписать, а не кванты от нимать. Время отклика (сюрпиз!) может быть и довольно большим.

2. Если у rt-процесса отнять квант, то системе точно *хана*. Ректор взорвётся, самолет упадёт и тд. Думайте головой.

3. Прочитайте спецификацию на жёсткий rt от ARINC, что ли.

sv75 ★★★★★
()
Ответ на: комментарий от cvs-255

> что произошла ошибка, остановит самолёт и пошлет спасателям сообщения о предстоящей катастрофе.

fixed

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

> Если он возиться дольше требуемого времени отклика --- это плохо и процесс надо переписать, а не кванты от нимать.

Например заклинило кран и он не может закрыться. Каким переписыванием процесса тут поможешь?

cvs-255 ★★★★★
()
Ответ на: комментарий от cvs-255

Системы реального времени надо испытывать перед эксплуатацией, да.

1. Это вы описали ввод-вывод. Это отдельная песня, кванты времени тут не причём, никто активно ждать while (opened()); не будет.

2. Если процесс совсем-совсем нарушает свой заявленный deadline --- да, его укокошат. Как последняя мера.

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

> Если у rt-процесса отнять квант, то системе точно *хана*.

Хана будет, если процесс вместо того, чтобы написать «не могу закрыть кран, сделайте что-нибудь», будет долго и бесполезно пытаться закрыть заклинивший кран

cvs-255 ★★★★★
()
Ответ на: комментарий от sv75

> Это вы описали ввод-вывод. Это отдельная песня

Системы мягкого и особенно жесткого реального времени в основном автоматикой и управляют

cvs-255 ★★★★★
()
Ответ на: комментарий от cvs-255

Автоматикой управляют не режиме активного ожидания, блин. ваш пример с краном --- не пример на кванты: в момент ожидания ввода-вывода квант отнимут и процесс будет ждать ввода-вывода! Но если он считает вычисления, квант не отнимут, пускай считает. Если процесс глючный --- это проблема тех, кто купил глючный софт для управления производством.

Скажите, вы хотя бы Таненбаума прочли?

sv75 ★★★★★
()

забавно читать все эти бурления на тему «realtime» =) я просто оставлю здесь это - давайте же узнаем что такое RT от самих авторов этих патчей

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от sv75

> Автоматикой управляют не режиме активного ожидания, блин.

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

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

>Это не только допустимо, это сама суть realtime (если не брать вещи вроде EDF, хотя... и для них тоже).

Это не только не допустимо а вообще противоречит принципам RT - гарантированное время отклика системы. При всем уважениии - ты какую-то хуйню несешь.

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