IRQL

IRQL (англ. Interrupt Request Level) — букв. «уровень запроса прерывания». Механизм программно-аппаратной приоритизации, применяемый для синхронизации в операционных системах семейства Windows NT.

IRQL является программным атрибутом (из-за того, что не поддерживается аппаратно) процессора и указывает приоритет кода, исполняющегося на этом процессоре по отношению к прерываниям и другим асинхронным событиям. Для аппаратных прерываний в большинстве случаев IRQL реализуется аппаратно (пример: понятие приоритета прерывания в контроллере i8259A или приоритет задачи, указываемый в регистре TPR в APIC), однако код операционной системы сам может логически находиться на разных приоритетах, в таком случае дополнительные уровни IRQL реализуются программно. Например, приоритет планировщика потоков или DPC выше, чем приоритет пользовательских потоков. Если бы это было не так, тогда потоки могли бы вытеснить планировщик и тем самым «отключить» вытесняющую многозадачность, в свою очередь планировщик может быть сделан прерываемым аппаратными прерываниями. В Windows NT применяется 32 уровня IRQL (в скобках указано числовое значение):

High (31)
Power fail (30)
IPI (29)
Clock (28)
Profile (27)
Диапазон аппаратных прерываний, называемых Devices IRQL, или DIRQL (от 26 до 3)
DPC/DISPATCH (2)
APC (1)
PASSIVE (0)

Это означает, например, что планировщик (работающий на уровне DPC/DISPATCH) может быть прерван аппаратными прерываниями, межпроцессорными прерываниями (IPI) и т. д., но не может быть прерван асинхронными процедурами (APC) и обычными потоками, работающими на уровне PASSIVE. Межпроцессорные прерывания IPI могут быть прерваны сбоем электропитания (прерывание на уровне Power fail), но не могут быть прерваны обычными аппаратными прерываниями от устройств и т. д.

Также IRQL помогает отслеживать и выявлять логические ошибки при проектировании ОС. Легендарная ошибка с сообщением IRQL_NOT_LESS_OR_EQUAL означает следующую ситуацию: драйвер или другой привилегированный код с IRQL >= DPC/DISPATCH обратился к отсутствующей^[1] в памяти странице, требуется вызов подсистемы, подгружающей страницы с диска, однако эта подсистема в соответствии с архитектурой Windows NT имеет IRQL меньше, чем DPC/DISPATCH. Следовательно, она не имеет права прерывать тот код, который вызвал ошибку страницы. В то же время привилегированный код не может продолжить выполнение, пока страница не будет загружена. Возникает логический тупик, который, собственно, и приводит к краху ОС.

При выполнении кода с IRQL >= DPC/DISPATCH, любое состояние ожидания от примитива синхронизации (мьютекса, семафора), приводит к краху ОС; Когда нынешний поток входит в это состояние, планировщик потоков должен запланировать другой поток на текущем ядре процессора. Но, поскольку приоритет планировщика равен DPC/DISPATCH, он не сможет прервать работу нынешнего потока.

В Linux применяются сходные механизмы. К примеру, код обработчика прерывания может быть разделен на две «половины»: top half и bottom half, «верхняя» часть эквивалентна собственно обработчику, «нижняя» — отложенной процедуре (аналог в Windows — DPC). Bottom-half-процедура может быть прервана Top-half-процедурой, но не наоборот. Таким образом, top-half и bottom-half логически эквивалентны уровням IRQL Device IRQL и DPC/DISPATCH, соответственно.

Соблюдение системных соглашенийПравить

Техническая документация Windows NT (библиотека MSDN) ограничивает непрерывное время работы кода на повышенных IRQL. Для уровней аппаратных прерываний (DIRQL) ограничение составляет 10-20 мкс^[2]. Для программного уровня DISPATCH_LEVEL даются противоречивые значения в 25^[3] и 100 ^[4] мкс.

Тем не менее, эти ограничения часто нарушаются даже собственным кодом ядра и драйверов Windows, не говоря уже о драйверах сторонних производителей, создавая скрытые задержки. Это не оказывает заметного влияния на обычную работу системы, однако может сильно ухудшать работу в реальном времени - например, в потоковом мультимедиа (особенно это заметно на звуке^[5] ^[6]). Для выявления подобных нарушений разработаны программы DPC Latency Checker (недоступная ссылка) (англ.) и LatencyMon (англ.). Анализ работы различных версий Windows при помощи подобных программ показывает, что указанные нарушения постепенно исправляются.

ЛитератураПравить

М. Руссинович, Д. Соломон. 1 // Внутреннее устройство Microsoft Windows. — 6-е изд.. — СПб.: Питер, 2013. — С. 111-121. — 800 с. — ("Мастер-класс"). — ISBN 978-5-459-01730-4.
Уолтер Они. Использование Microsoft Windows Driver Model. — 2-е изд.. — СПб.: Питер, 2007. — С. 166-172. — 764 с. — ISBN 978-5-91180-057-4.
Understanding IRQL Архивная копия от 8 декабря 2017 на Wayback Machine (англ.).

ПримечанияПравить

↑ Код, выполняющийся с IRQL >= DPC/DISPATCH, должен обращаться к данным, в т.н. «Невыгружаемом пуле» Windows NT.
↑ Synchronization Examples Архивная копия от 2 марта 2016 на Wayback Machine (англ.)
↑ Introduction to Spin Locks Архивная копия от 2 марта 2016 на Wayback Machine (англ.)
↑ Guidelines for Writing DPC Routines Архивная копия от 2 марта 2016 на Wayback Machine (англ.)
↑ Windows Vista Tuning Tips for Audio Processing Архивная копия от 25 марта 2016 на Wayback Machine (англ.)
↑ Windows XP Tuning Tips for Audio Processing Архивная копия от 25 марта 2016 на Wayback Machine (англ.)

[1] Код, выполняющийся с IRQL >= DPC/DISPATCH, должен обращаться к данным, в т.н. «Невыгружаемом пуле» Windows NT.

[2] Synchronization Examples Архивная копия от 2 марта 2016 на Wayback Machine (англ.)

[3] Introduction to Spin Locks Архивная копия от 2 марта 2016 на Wayback Machine (англ.)

[4] Guidelines for Writing DPC Routines Архивная копия от 2 марта 2016 на Wayback Machine (англ.)

[5] Windows Vista Tuning Tips for Audio Processing Архивная копия от 25 марта 2016 на Wayback Machine (англ.)

[6] Windows XP Tuning Tips for Audio Processing Архивная копия от 25 марта 2016 на Wayback Machine (англ.)

[1]

[2]

[3]

[4]

[5]

[6]