Проблема 1: Время обработки прерываний

Блокированный процесс, ожидающий конца некоторого запроса ввода - вывода становится исполняемым снова, когда CPU получает прерывание от устройства ввода - вывода, которое обработало запрос. Время, которое проходит между прерыванием и реакцией на особую ситуацию обработчика прерываний, называется "временем входа в прерывание". Время которое проходит между прерыванием и продолжением выполнения блокированного процесса назвается "временем обслуживания прерывания". Мы предполагаем что блокированный процесс - процесс с самым высоким приоритетом (POSIX.1b системные запросы планировщика позволяют гарантировать это).

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

В настоящее время, Linux имеет в основном два типа обработчиков особых ситуаций: "быстрый" и "медленный".

"Медленные обработчики прерываний" на особую ситуацию вызывают планировщик каждый раз немедленно после того, как прервание было обработано. Это гарантирует, что если процесс стал исполняемым обрабатывая прерывание и имеет самый высокий приоритет, тогда он непосредственно получит контроль над CPU после обработчика реакции на особую ситуацию. Это гарантирует быструю обработку прерывания, но платой будет то, что планировщик запускается после каждого прерывания, и это может резко снизить производительность системы для устройств с высокой скоростью прерываний (например, сетевые контроллеры).

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

"Быстрые обработчики" только отмечают в бит-маске номер устройства, которое вызвало прерывание и должно быть обработано. Планировщик не вызывается после быстрого прерывания и процесс ожидающий прервания может ждать до 1 s / HZ = 10 ms до следующего прерывания от таймера, которое вызывет планировщик снова (потому что прерывания таймера обработывают "медленный" путь). "Быстрые" обработчики прерываний - это те, которые установлены драйвером со спецификацией SA_INTERRUPT при запросе request_irq().

"Быстрый" обработчик - причина, почему для устройств подобно последовательному порту, время обработки прерывания может легко достигнуть 10 ms и больше. "Быстрые" обработчики запрещают другие прерывания в то время, когда выполняется обработчик. Это увеличивает время входа в прерывание. Linux "быстрые" обработчики прерываний очень слабо нагружают драйверы, но они могут быть причиной не малой головной боли для разработчиков прикладных программ в реальном масштабе времени.

См. linux/arch/i386/kernel/irq.c, linux/include/asm-i386/irq.h и linux/arch/i386/kernel/entry.S на предмет исполнения как быстрых и медленных обработчиков в Linux.

Примеры для "медленного" Linux 1.3 драйверы прерываний с хорошим временем обработки прерываний: клавиатура, флоппи- диск, таймер, соунд- карты, некотоые Ethernet карты.

Примеры для "быстрого" драйвера прерываний с плохим временем обработки: последовательный порт, некоторые Ethernet карты, большинство harddisk/SCSI драйверов, большинство CD-ROM драйверов.

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

Кроме "быстрого" обработчика, другая важная причина минимизации времени обработки прерывания в последовательном порте - 16550 FIFO UART. В настоящее время, UARTы конфигурируются, чтобы вызвать прерывания (исключая скорости < 2400 bit/s ) только, если FIFO заполнен по крайней мере восьмью байтами, или если случился UART-timeout (это случается после четырехкратного времени передачи символа). 16550 чип может быть сконфигурирован, чтобы установить 1, 4, 8, и 14, но в Linux в настоящее время нет ioctl() для этого.

Детально относительно FIFO UART, пожалуйста консультируйтесь с National Semiconductor PC16550D описанием, которое доступно на: URL:
http://www.nsc.com/pf/PC/PC16550D.html