IRQL (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 (англ.).

Примечания

[править | править код]
  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 (англ.)