а что, у линукса только сейчас появилась возможность многопоточной обработки прерываний?
я правильно понимаю, что имеется ввиду возможность ядра выполнятся в контексте обработчика прерывания на нескольких камнях, без взаимоблокировок (или с их минимумом, т.е. без GL)?

По-моему, речь идет о разделении выполнения прерывания на "железную" и "софтверную" часть, причем последняя вызывается первой как отдельный поток. У "софтверных" частей взаимоблокировки сведены к минимуму.

http://lwn.net/Articles/302043/

QNX-капец?

До QNX -rt ядро пока не дотягивает. Но достаточно близко.

ни разу не близко. ОСРВ- это не только ядро.

ОСРВ.

>ни разу не близко. ОСРВ- это не только ядро.

А что ещё?

И что у этого ядра с совместимостью с существующими программами для Linux? Возможно ли использовать такое ядро с обычной Gentoo или Ubuntu? Если использовать на десктопе, то что будет с временем реакции? Имеет ли смысл ставить такое ядро на маршрутизатор/сетевой фильтр?

Ждем ебилдов

>И что у этого ядра с совместимостью с существующими программами для Linux? Возможно ли использовать такое ядро с обычной Gentoo или Ubuntu? Если использовать на десктопе, то что будет с временем реакции? Имеет ли смысл ставить такое ядро на маршрутизатор/сетевой фильтр?

уже давно используют на десктопах для того чтобы гуй не висел.

RT ядра на десктопах? Это в каком дистрибутиве ?

> http://lwn.net/Articles/302043/
спасибо за ссылку

> По-моему, речь идет о разделении выполнения прерывания на "железную" и "софтверную" часть, причем последняя вызывается первой как отдельный поток.
soft irq давно есть. только теперь они хотят их в отдельных kernel threads пускать.

В Убунте есть в репах. а в Убунту Студио - искаропки.

а в конфиге ванильного ядра Preemption Model (Preemptible Kernel (Low-Latency Desktop)) что такое?

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

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

> Основная идея - максимально быстро выскочить из обработчика прерываний, оставив работу по дальнейшей обработке в потоке ядра, это снижает латентность.
... и это вполне себе достигается с помощью software interrupt. основная идея - управление приоритетом потока обработчика через шедулер и найс. таким образом понижается латентность пользовательских процессов, если в системе присутствует нагруженный драйвер с кучей прерываний. разумеется, в ущерб драйверу. многие драйверы сетевых карт и так имеют механизмы адаптации к загруженности. теперь есть универсальный официальный метод для всех.

>снижает латентность.

А я то думал что снижает латентность и повышает очевидность использование Mac OS X

Читать умеешь?

to reduce the time spent with interrupts disabled to a bare minimum

"Сократить время проведенное с запрещенными прерываниями, к минимуму, определяем железом."

При чем тут приоритеты обработчиков непонятно.

>> "Сократить время проведенное с запрещенными прерываниями, к минимуму, определяем железом."

> При чем тут приоритеты обработчиков непонятно.

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

стоит, на старом компе - с убунта-rt грузилось всё хоть и чуть медленнее, но работать было приятней

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

> RT ядра на десктопах? Это в каком дистрибутиве ?

В Gentoo есть, очевидно.

В Gentoo есть всё, даже freebsd-sources.

>В Gentoo есть, очевидно

ткни носом, что то в портеже не нашел я его

сказки Орденского леса.

layman -a pro-audio
emerge rt-sources

http://gpo.zugaina.org/ - наш друг.

Жаль что там ни reiser4, ни BFQ нет.. а Zen-sources RT подохли.

В дебиан тоже есть freebsd-sources, по крайней мере ядро.

>Жаль что там ни reiser4, ни BFQ нет.. а Zen-sources RT подохли.

Да по-моему, -zen вообще загнулся. последняя версия в оверлее - .29-r1

А по слухам уже .30 вышло )

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

есть ли внятное объяснение того, что ее нет в ванильном ядре?

Кагбэ 4.2 Брал 2.6.30-rc8 с гита пару недель назад.

Хм... С git'а говоришь... Я как гентушник обычно оверлеем пользовался, но он, видимо, заглох.

>в оверлее

Руками, руками. Linux devl547 2.6.30-zen0

А скажите, что это дает на десктопе, например в ubuntu-studio от него польза есть?

> А скажите, что это дает на десктопе...?

Если нет rt специфики (напр. риалтайм обработка звука или видео), то ничего.

А как насчет шустрости гуя?

Может сделать только хуже

не знаю как сейчас, а раньше в qnx гуй был очень тормозным.

так что это ортогональные вещи.

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

>Если нет rt специфики (напр. риалтайм обработка звука или видео), то ничего.

например меньше вероятность прерывания проигрывания звука в то время когда жестоко мучаешь систему.

Спасибо. Буду тестировать.

>RT ядра на десктопах? Это в каком дистрибутиве ?



dudraug@dudraug-laptop:~/Рабочий стол$ apt-cache policy linux-image-rt
linux-image-rt:
  Установлен: (отсутствует)
  Кандидат: 2.6.28.3.1
  Таблица версий:
     2.6.28.3.1 0
        500 http://archive.ubuntu.com jaunty/universe Packages

А сколько на писюке жёстких realtime задач можно запустить... 1?

тока кончил собирать ядро реального времени... правда под Ubuntu 8.04 Server (а след и версия 2.6.24 =) )

> Читать умеешь?
спокойно, спокойно. прочитай всю статью, а не отдельную фразу. и комменты (от автора статьи). там вполне доступно написано, зачем они это сделали, и при чем тут приоритеты потоков ядра.
время пребывания в hardware interrupt они уменьшили, но весьма незначительно, обычно там и так ничего не делают, все выносят в софтинт. а теперь каждый запускаемый обработчик софтинт - отдельный поток ядра.

сколько в производительность влезет - столько и можно

суся радует количеством РТ ядер, вот уже сижу на свежесобранном 2.6.30-rt

Архитектура системы вообще. Лично я работаю с QNX. Совместимость с программами под Linux очень низкая- потому что ПО для Linux ориентировано на «мягкое» реальное время. Ядро (сам не пробовал, только догадки) можно засунуть при желании в Генту или другой дистрибутив, но опять таки, эта система изначально не была задумана как десктопная, то есть почти полное отсутствие вменяемых драйверов для видеокарт и других ненужных для выполнения основной задачи системы устройств. Основное применение- это автоматизация на производстве (очень часто ставят во встраиваемые системы, формата CPCI, PC/104 и прочее), поэтому там выстроена своеобразная система приоритетов ядра и выделения памяти. 
Ставить такое ядро на маршрутизатор/ сетевой фильтр я бы не советовал, если не критична скорость реакции на изменения в оборудовании и нет упора на обработку внешних событий, чего в сети нет. Сеть как-раз является примером работы системы мягкого реального времени- если система обработала принятый пакет, это приведет к остановке на передающей стороне и повторной посылке (в зависимости от протокола), а в ОСРВ такая ситуация просто недопустима, потому что ОСРВ никогда не опоздает с реакцией на событие

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

Что такое "многопоточная обработка прерываний" для тебя? %)

> я правильно понимаю, что имеется ввиду возможность ядра выполнятся в контексте обработчика прерывания на нескольких камнях, без взаимоблокировок

Нет. Имеется в виду оформление обработчиков прерываний в виде пот^Wнитей, с возможностью их планирования стандартными средствами.

> Архитектура системы вообще.

А можно подробнее? "Архитектура системы вообще" - это SRR?

> Ставить такое ядро на маршрутизатор/ сетевой фильтр я бы не советовал

А Cisco (?) именно так и сделали.

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