Реальное время в Linux

Alexey Vissarionov написал(а) к Eugene Muzychenko в Nov 20 19:05:00 по местному времени:

Доброго времени суток, Eugene!
28 Nov 2020 09:39:50, ты -> мне:

AV>> Ты объем этих исходников видел? Там где-то порядка гигабайта.
EM> Гигабайт - это весь линукс. Для реализации сколь угодно жесткого RT
EM> достаточно доработать лишь ядро, а это несколько десятков мегабайт
EM> максимум.

А "весь Linux" - это и есть ядро. Как я уже написал в прошлом сообщении, монолитное модульное.

AV>> Переписывать, конечно, нужно не все, но многое.
EM> Многое-то зачем? Или там в ядре полно мест, где слишком долго держат
EM> блокировки, многократно ходят по одним и тем же спискам, и т.п.?

Да об этом в принципе никто не задумывался. Есть таймер, который срабатывает CONFIG_НZ раз в секунду (на серверах - 100, на десктопах - 250, 300 или 1000 ценой небольшой потери производительности): получили квант времени - работаем; закончили досрочно - вернули управление, планировщик разберется; не успели - опаньки, ждем следующего кванта времени.

gremlin@ws:~ > zgrep ^CONFIG_НZ= /proc/config.gz
CONFIG_НZ=100

Да, я использую серверное значение на десктопе. Мне можно, ибо я точно знаю, зачем мне именно такая настройка :-)

AV>> Производительность != быстродействие
EM> Сейчас я говорю исключительно о времени реакции на события, а оно
EM> пропорционально прежде всего тактовым частотам.

Нет - оно (точнее, его матожидание) пропорционально

AV>> Напомню, писюшный флоп - это чистейшее GPIO-устройство.
EM> Не только писюшный - их таких немало было в те времена.

Писюшный - самый известный.

EM> Но интеллектуальный контроллер флопа с DMA появился еще при DOS,

Где-то во времена пней-2...пней-3, если правильно помню. Лет 20 назад.
И работать с ним можно было только через int 0x13 - это сразу убило все говнозащиты от копирования, использовавшие дискеты в качестве ключевого носителя.

EM> а анекдот про "истинно многозадачную систему Windows" описывает
EM> DOS-based версии винды. В любой NT флоп работал так же независимо,
EM> как и НDD.

Независимо, ага... но медленно и печально.

AV>> Лично я эту поебень даже в ядро вкомпилячивать не буду. Ибо
AV>> кроилово, традиционно ведущее к попадалову.
EM> Ты не понял. Я не предлагаю делать программно то, что занимает
EM> достаточно много ресурсов (обмен большими массивами данных,
EM> формирование сигналов заданной формы и т.п.). Основная идея - это
EM> получение от ОС предсказуемого времени реакции на событие,
EM> определяемого только быстродействием железа и разумными накладными
EM> расходами на поиск обработчика прерывания, переключение контекста и
EM> т.п.

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

EM> Сейчас, насколько я понимаю, в линуксе этой предсказуемости нет, как
EM> и в винде.

Угадай, почему.

EM> Событие по схеме "сигнал-прерывание-драйвер-процесс" в одном случае
EM> может быть передано процессу через 100 мкс, а в другом - через 5 или
EM> 20 мс.

Это вполне нормально. Если тебе нужно гарантированное время отклика - ставь лошадьтроллер, который будет работать с оборудованием в realtime, а данными с системой обмениваться асинхронно.

То есть, не "произошло событие, что делать?", а "тут было вот такое событие, отреагировал вот так, что делать дальше?". Но это дуууумать наааадо...

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

И не надо - это забота софта, работающего внутри лошадьтроллера.

EM> А железо позволяет делать это на интервалах даже в сотни микросекунд,
EM> но система, из-за недостатков ядра, этого не тянет. Неужто не досадно?

А с чего мне должно быть досадно?

EM> Идея отнюдь не в том, чтобы регулярно дрочить регистры десятки-сотни
EM> тысяч раз в секунду, а в том, чтобы обработать разумное (максимум -
EM> сотни-тысячи в секунду) количество событий максимально близко к
EM> моментам их возникновения.

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


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii

... Вопрос понял, ответ думаю
--- /bin/vi