Вот есть процесс в user space Linux. Он в цикле опрашивает порт IO (через медленную функцию доступа к IO из user space). Если там что-то случилось/не случилось, он делает некую работу.

Есть другие процессы (и сама система). Они прерывают мой процесс. Процессов таких минимум, они не сильно активны. По сети активности нет. Винчестера нет, только NOR FLASH и SD.

Если вести речь о PXA270, на 312 Мгц, то о какой "временной девиации" может идти речь? Т.е. на какое максимальное время система может прервать мой процесс? Можно ли говорить о том, что "дырка" будет не более 10 мс?

Аспекты kernel module, RTAI чур пока не трогать. Реь идет о тупом программизме в user space.

Тут еще вопрос в том, с какой частотой будет вызываться шедулер. Если период вызова шедулера будет больше или равна 10 мс, то, понятно, "дырка" может быть больше 10 мс.

В стандартном варианте, насколько я понимаю, 10 мс. Можно ли говорить о том, что "дырка" будет не более 50...100 мс?

Это можно будет утверждать только при жестко заданных условиях: какие процессы запущены, их приоритеты, какие прерывания активны и как часто они возникают, сколько времени может отнять обработка отдельного прерывания. Если знать все эти параметры, то, думаю, можно уложиться в 50 мс.

Понятно, что без описания всей остальной системы вопрос, мягко говоря, не сильно корректный. Но мне пока важно качественно понять продолжительность "дырки".

Т.е. можно говорить, что если не "дурить" в остальной части системы, время дырки для моего процесса не будет превышать 100мс. Это меня устраивает!

Задам свой вопрос.
Если написать демон или драйвер, и запустить всё это в kernel space, то что можно ожидать по задержкам?

Ни фига не гарантируется, вот навскидку несколько моментов, которые легко удлиняют switch_task jitter в несколько раз :
- способ реализации вкомпиленных в ядро драйверов устройств - любой драйвер в состоянии запретить прерывания на столько, на сколько он захочет, причем может быть неважно есть данное устройство в системе или нет
- способ взаимодействия контроллера памяти и DMA с CPU - есть всяческие пересылки, которые постоянно происходят в системе, они захватывают шину, вопрос на сколько - обычно задержки такого рода минимальны
- способ реализации захвата шины процессора набортными платами, тут поле непаханое, вот пример из Intel мира - чипсет i810/i815 с набортным видео в состоянии удерживать шину CPU до 1мс ! т.е. в зависимости от типа обмена легко получаем jitter на данных системах до 100мс

Вывод: только комплексный и правильный выбор hard и soft архитектуры может решить вопросы данного рода с порядочной долей вероятности, ну и тесты, тесты и тесты ...

Хм... Я говорил про embedded систему на PXA270. Вроде там i810/i815 не шибко нужен

Вообще "дело ясное, что дело темное". Но 100 мс, как я уже говорил, меня устраивает на крайний случай.

Вообще, по моему скромному мнению, следует внести опрос портов IO в kernel space с последующей записью в файл устройства. А далее из user space жрать из этого файла устройство все, что надо.
Если есть беспокойство по поводу того, что ядро не даст нужного приоритета для kernel module, есть один вариант (я как-то его реализовывал, но придумал не сам). Если надо, потом попробую описать.

Kernel module работает как часть ядра, т.е. о приоритете говорить не совсем корректно. Другое дело механизм передачи управления функциям из модуля. Тут есть варианты, начиная с древних BH-handlers и заканчивая потоками ядра.

Я имел в виду немного другое. В свое время пришлось решать задачу по использованию дополнительной клавиатуры, которая сидела на томже прерывании, что и стандартная. Только скан-коды у нее начинались с E1. Погеморроиться пришлось прилично. Ядро попросту игнорировало эти скан-коды. А править и пересобирать его нельзя было по условиям задачи.

- в стандартном варианте - 10мс., но при ядре старше 2.6.х вы можете эту дискретность уменьшить.

- но вы можете просто не позволять решедулировать этот процесс user space другими, играясь приоритетом и политикой диспетчеризации, тогда дискретность вам вообще до фени (только не забыть устранить всякое "динамическое управление приоритетом" со стороны ОС):



- это, в общем случае, так, но у вас, по сказанному раньше, нет особенно с фокусами ни юзеровских ни системных процессов?

- неприятность в том, что кроме штатного решедулирования вам большую (во много раз) дисперсию могут "подарить" другие механизмы: возникновение свопинга (который должен быть напрочь исключён), ... инверсия приоритетов, которую можно создать уже при 3-х процессах/потоках...
Смотрите и в эту сторону.

P.S. а вообще, именно из-за этого, что механизмы никакого Linux не гарантируют невозникновение каких-то задержек на все-все 100% - это заложено в идеологии системы - Linux ни с какими приставками RT не будет до конца RT (даже при 2-х ядерности)...
Хотя у некоторых здесь бытует мнение, что всякое RT - это некий мистификасьён ... - может они что-то знают, и будем им верить?

А kernel module никак и не решит вашу проблему: он может уменьшить и детерминировать время латентности на прерывание, или I/O операции ... но вас ведь интересует "временная девиация" в пользовательском приложении, так?

Это правильно, но есть одна загвоздка - надо уметь писать программы для kernel space.

... вот только в user space до этого нужно ждать (может и до бесконечности) RUNNING и доступа к этому файлу устройства...