Реальное время в 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

Eugene Muzychenko написал(а) к Alexey Vissarionov в Nov 20 18:01:37 по местному времени:

Привет!

28 Nov 20 18:53, you wrote to me:

AV> Форточка - это единственная система с микроядром

Микроядро в форточке было только в самых ранних, экспериментальных, версиях NT, которые в России видело лишь небольшое количество энтузиастов. Подавляющее большинство (я в том числе) увидело NT, начиная с версий 3.x, с классическим гибридным (монолитным модульным) ядром. Это стык конца 80-х и самого начала 90-х.

AV> Все остальные (актуальные) ядра - монолитные: там есть только Ring0 и
AV> Ring3, соответствующие ядру (kernel) и пользовательскому окружению
AV> (userspace).

Это и есть виндовое ядро. :) Только в десятке к нему сбоку прикрутили гипервизор, реального смысла в котором не видит никто, кроме юзеров, ежедневно цепляющих новую малварь - он более-менее спасает от руткитов. Всех остальных он "спасает" от возможности патчить ядро, за что среди профессионалов его не любят.

AV> Да, сразу отвечу и на стандартный вопрос про модули: при их загрузке
AV> (man insmod) происходит не запуск через execve(), а именно загрузка в
AV> адресное пространство ядра и установка указателей на функции,
AV> содержащиеся в модуле.

Форточка загружает драйверы точно так же. Разница лишь в том, что для форточного драйвера изначально предусмотрены протоколы, через которые с ним работает система (простейшие для legacy и более сложные - для PnP), а в линуксе модуль, загрузившись, должен сам объяснить системе, кто он такой есть, и что ему нужно.

Но вопрос-то остается: что плохого в наличии у ОС гарантированной скорости реакции на события?

Всего доброго!
Евгений Музыченко
eu-gene@muzy-chen-ko.net (все дефисы убрать)

--- GoldED+/W32-MSVC 1.1.5-b20170303

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

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

AV>> Форточка - это единственная система с микроядром
EM> Микроядро в форточке было только в самых ранних, экспериментальных,
EM> версиях NT, которые в России видело лишь небольшое количество
EM> энтузиастов. Подавляющее большинство (я в том числе) увидело NT,
EM> начиная с версий 3.x, с классическим гибридным (монолитным модульным)
EM> ядром. Это стык конца 80-х и самого начала 90-х.

Да? А вот в этих ваших интернетах пишут, что %windir/system32/ntoskrnl.exe работает в ring0, всякие драйверы в ring1, системные процессы в ring2, а пользовательские процессы в ring3... Неужели врут?

AV>> Все остальные (актуальные) ядра - монолитные: там есть только Ring0
AV>> и Ring3, соответствующие ядру (kernel) и пользовательскому окружению
AV>> (userspace).
EM> Это и есть виндовое ядро. :) Только в десятке к нему сбоку прикрутили
EM> гипервизор, реального смысла в котором не видит никто, кроме юзеров,
EM> ежедневно цепляющих новую малварь - он более-менее спасает от руткитов.
EM> Всех остальных он "спасает" от возможности патчить ядро, за что среди
EM> профессионалов его не любят.

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

AV>> Да, сразу отвечу и на стандартный вопрос про модули: при их загрузке
AV>> (man insmod) происходит не запуск через execve(), а именно загрузка
AV>> в адресное пространство ядра и установка указателей на функции,
AV>> содержащиеся в модуле.
EM> Форточка загружает драйверы точно так же. Разница лишь в том, что
EM> для форточного драйвера изначально предусмотрены протоколы, через
EM> которые с ним работает система (простейшие для legacy и более
EM> сложные - для PnP),

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

EM> а в линуксе модуль, загрузившись, должен сам объяснить системе,
EM> кто он такой есть, и что ему нужно.

Ядро само из него читает унифицированные структуры - он же в его адресном пространстве находится. Посмотри макросы moduleinit() и moduleexit() в include/linux/module.h

EM> Но вопрос-то остается: что плохого в наличии у ОС гарантированной
EM> скорости реакции на события?

Что плохого в КПД 100% ? :-)


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

... Приручив собаку, человек потерял нюх, а освоив интернет - теряет мозг
--- /bin/vi

Eugene Muzychenko написал(а) к Alexey Vissarionov в Nov 20 23:18:37 по местному времени:

Привет!

28 Nov 20 19:05, you wrote to me:

EM>> Гигабайт - это весь линукс.

AV> А "весь Linux" - это и есть ядро.

Если "ядром Linux" ты называешь все, что лежит в kernel address space, то какие различия ты видишь между этой сущностью в линуксе и винде? :)

AV> Как я уже написал в прошлом сообщении, монолитное модульное.

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

Вообще, какое значение имеет модульность ядра в обсуждаемом вопросе?

EM>> Или там в ядре полно мест, где слишком долго держат блокировки,
EM>> многократно ходят по одним и тем же спискам

AV> Да об этом в принципе никто не задумывался.

То-то я гляжу, профессиональных звуковых студий под линукс не делают - только под винду и макось. На слух-то даже миллисекундные разрывы заметны прекрасно, а вот в видео кадры можно на десятки миллисекунд двигать вперед-назад без малейших проблем для восприятия.

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

А сумеешь без тестов, чисто органолептически, определить, с какой частотой у тебя работает таймер? :) Я вот на винде не отличу, когда он со стандартных 16 мс переходит на минимальные 500 мкс и обратно. :)

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

AV> Где-то во времена пней-2...пней-3, если правильно помню. Лет 20 назад.

Лет 35 назад, во середине 80-х - i8272A. :) А все "интеллектуальные" чипсеты со времен AT (конец 80-х) включали функциональность i82077A.

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

Ты явно что-то путаешь. Все контроллеры, что делали после uD765, были с ним программно совместимы, и работать с диском непосредственно через контроллер (там, где он еще оставался) можно было так же, как и в 80-х. Старые защиты убивались по мере смены форматов: то, что было заточено под SD-дискеты на 360 кб, закономерно ломалось на дискетах DD/QD, поскольку менялись продольные параметры дорожек, вводились флаги их поперечной плотности и т.п.

EM>> В любой NT флоп работал так же независимо, как и НDD.

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

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

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

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

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

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

Не могу угадать. В винде ее нет прежде всего потому, что ее многие драйверы (ACPI, USB, NDIS и другие) с момента своего появления нарушают виндовые же ограничения времени выполнения на повышенных приоритетах. Периодически их фиксят в наиболее тормозных местах, но программисты MS, как известно, не делают этого по собственной инициативе. Скажут - будут изучать и фиксить, не скажут - оно будет тормозить еще десять или двадцать лет. А вот кто и зачем может мешать оптимизировать проблемные места в линуксовом ядре и драйверах - не знаю.

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

AV> Это вполне нормально.

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

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

И до какой степени система при этом сможет тормозить с откликом? :) 5 мс? 10? 20? 50? 100? :) Где тут граница между "вполне допустимо" и "ну, это уже безобразие", и почему? :)

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

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

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

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

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

А когда быстродействие центральных процессоров достигнет, например, триллиона операций в секунду - это тоже будет "аппаратная задача для отдельного контроллера"? :) Или тогда в отдельном контроллере уже будет крутиться линукс, а критичный ко времени софт - в еще более отдельном? :)

Всего доброго!
Евгений Музыченко
eu-gene@muzy-chen-ko.net (все дефисы убрать)

--- GoldED+/W32-MSVC 1.1.5-b20170303

Eugene Muzychenko написал(а) к Alexey Vissarionov в Nov 20 10:13:25 по местному времени:

Привет!

28 Nov 20 22:30, you wrote to me:

AV> А вот в этих ваших интернетах пишут, что %windir/system32/ntoskrnl.exe
AV> работает в ring0, всякие драйверы в ring1, системные процессы в ring2,
AV> а пользовательские процессы в ring3... Неужели врут?

Про системы до десятки - однозначно врут, не читай те интернеты. Я, как бы, двадцать лет пишу под ядро NT, так что немного знаю, что и как там работает. :)

AV> Гипервизор есть в любом уважающем себя ядре. И не сбоку, а в основе
AV> защиты памяти.

Ну так эти гипервизоры, что виндовый, что линуксовый, работают на так называемом "ring -1" за счет дополнительной аппаратной виртуализации. Но линуксовый, насколько я знаю, не занимается контролем доступа в ядро, а лишь помогает его виртуализовать для виртуальных машин.

EM>> Форточка загружает драйверы точно так же.

AV> Насколько я пони мяу, именно поэтому они и работают в ring1.

Они всегда работают в ring 0, как и все ядро, кроме гипервизора (а до десяток - и вообще все).

AV> Ядро само из него читает унифицированные структуры - он же в его
AV> адресном пространстве находится. Посмотри макросы module_init() и
AV> module_exit()

Я там вижу, что само (без явного указания от модуля) ядро ничего из модуля не читает. В module_init передается адрес функции, которая вызывается для инициализации модуля. Обычно она регистрирует драйвер в системе - в ходе этого передаются и структуры. Но может и тупо завершиться - тогда, насколько я понимаю, модуль просто останется в АП ядра, но никто к нему обратиться не сможет.

EM>> Но вопрос-то остается: что плохого в наличии у ОС гарантированной
EM>> скорости реакции на события?

AV> Что плохого в КПД 100% ? :-)

Не понял. :) КПД 100%, судя по всему, недостижим в силу объективных свойств мира. А гарантированная скорость реакции вполне достижима, и на современном железе это отнюдь не миллисекунды, а максимум десятки микросекунд.

Всего доброго!
Евгений Музыченко
eu-gene@muzy-chen-ko.net (все дефисы убрать)

--- GoldED+/W32-MSVC 1.1.5-b20170303