Предопределенные IRQL
Давайте повнимательнее приглядимся к предопределенным IRQL, начиная с самого верхнего уровня схемы, представленной на рисунке Рис_1 .
Уровень «High» (высокий) используется ядром, только если оно останавливает систему в функции KeBugCheckEx и маскирует все прерывания. Уровень «power fail» (отказ электропитания) был заложен еще в самый первый проект Microsoft Windows NT.Он определяет поведение системы при отказе электропитания, но никогда не применялся. Уровень «interprocessor interrupt» (межпроцессорное прерывание) используется для того, чтобы запрашивать от другого процессора выполнение какой-либо операции, например, при постановке в очередь прерывания DISPATCH_LEVEL для планирования конкретного потока к выполнению, при обновлении кэша TLB, завершении работы или крахе системы. Уровень «clock» (часы) используется для системных часов, с помощью которых ядро отслеживает время суток, измеряет и распределяет процессорное время между потоками. Уровень «profile» (профиль) используется системным таймером реального времени, если активизирован механизм профилирования ядра (kernel profoling), т.е. Измерения его производительности.Когда он активен, обработчик ловушки профилирования регистрирует адрес команды, выполнявшейся на момент прерывания.Со временем создается таблица адресов, которую можно извлечь и проанализировать с помощью соответсвующих утилит. Уровень «device» (устройство) применяется для задания приоритетов прерываний от устройств. Прерывания уровней «DPC/dispatch» и «APC» являются программными; они генерируются ядром и драйверами устройств. Самый низкий уровень IRQL, «passive» (пасивный), на самом деле вообще не является уровнем прерывания.При этом значении IRQL потоки выполняются обычным образом и могут возникать любые прерывания.
ЭКСПЕРИМЕНТ: применение утилиты Kenrate
Утилита профилирования ядра (Kenrate) позволяет включать таймер профилирования системы, собирать образцы кода, выполняемого при срабатывании таймера, и выводить сводную информацию, отражающую распределение процессорного времени по образам файлов и функциям.Её можно использовать для отслеживания процессорного времени, потребляемого индивидуальными процессами, и/или времени, проведенного в режиме ядра независимо от процессов (например, для выполнения процедур обслуживания прерываний).Профилирование ядра полезно, когда вы хотите выявить точки, в которых на выполнение кода тратится больше всего процессорного времени. В своей простейшей форме Kenrate сообщает, сколько процессорного времени было использовано каждым модулем ядра (Ntoskrnl, драйверами и т.д.).Попробуйте, к примеру, выполнить следующие операции. Откройте окно командной строки. Введите cd "C:\Program Files\KrView\Kernrates". Введите dir. (Вы увидите образы Kernrate для каждой платформы.) Запустите образ, который подходит для вашей платформы (без аргументов или ключей).Например, Kernrate_i386_XP.exe — это образ для Windows XP на платформе х86. Пока Kernrate выполняется, поделайте что-нибудь в системе.Скажем, запустите Windows Media Player и проиграйте музыку, запустите игру, интенсивно работающую с графикой, или перечислите содержимое каталога на удаленном сетевом ресурсе. Нажмите Ctrl+C, чтобы остановить Kernrate.Это заставит Kernrate вывести статистику за прошедший период.
Если у вас есть файлы символов, вы можете исследовать индивидуальные модули и посмотреть, сколько времени было затрачено каждой из их функций. |
На код, выполняемый на уровне «DPC/dispatch» и выше, накладывается важное ограничение: он не может ждать освобождения объекта, если такое ожидание заставило бы планировщик подключить к процессору другой поток (а это недопустимая операция, так как планировщик синхронизирует свои структуры данных на уровне «DPC/dispatch» и, следовательно, не может быть активизирован для выполнения перераспределения процессорного времени).Другое ограничение заключается в том, что при уровне IRQL «DPC/dispatch» или выше доступна только неподкачиваемая память.На самом деле второе ограничение является следствием первого, так как обращение к отсуствующей в оперативной памяти странице вызывает ошибку страницы.Тогда диспетчер памяти должен был бы инициировать операцию дискового ввода-вывода, после чего ждать, когда драйвер файловой системы загрузит эту страницу с диска.Это в свою очередь вынудило бы планировщик переключить контекст (возможно, на поток простоя, если нет ни одного пользовательского потока, ждущего выполнения).В результате было бы нарушено правило, запрещающее вызов планировщика в таких ситуациях (поскольку при чтении с диска IRQL все еще остается на уровне «DPC/dispatch» или выше).При нарушении любого из этих двух ограничений происходит крах системы с кодом завершения IRQL_NOT_LESS_OR_EQUAL.Кстати, нарушение этих ограничений является довольно распространенной ошибкой в драйверах устройств. |
Комментариев нет:
Отправить комментарий