Зумовлені irql-рівні
Давайте придивимося до використання до попередньо встановлених IRQL, починаючи з найвищого рівня:
- Ядро використовує високий рівень (high), тільки коли воно зупиняє систему в функції KeBugCheckEx і маскує всі переривання.
- Рівень збою електроживлення (power fail) вперше згадується в початкових документах про конструкції Windows NT. Він визначає поведінку системного коду при перебої в постачанні електроенергії, але цей IRQL ніколи не використовувався.
- Рівень межпроцессорного переривання (interprocessor interrupt) використовується для запиту виконання дії на іншому процесорі, наприклад, для поновлення кеш-пам`яті процесорного TLB, завершення роботи системи або при аварійному відмову системи.
- Рівень годин (clock) використовується для внутрішнього годинника. З його допомогою ядро відстежує час доби, а також вимірює і виділяє потокам час центрального процесора.
- Системний годинник реального часу (або інше джерело, наприклад, локальний таймер APIC) використовують при включенні профілювання ядра (при залученні механізму вимірювання продуктивності) рівень profile.
При активному стані профілювання ядра його обробник системного переривання записує адресу коду, який виконувався в той момент, коли виникло переривання. Згодом створюється таблиця вибірки адрес, яку можна витягти і проаналізувати за допомогою інструментів.
Для настройки і перегляду згенерованої при профілювання статистики можна використовувати такий засіб, як Kernrate, що входить до складу Windows Driver Kit (WDK). Додаткова інформація про використання даного засобу дана в експерименті, проведеному з Kernrate.
- IRQL синхронізації (synchronization) використовується всередині операційної системи кодом диспетчера і планувальника для захисту доступу до глобального потоку планування і до коду очікування-синхронізації. Зазвичай цей рівень визначається як найвищий відразу ж після IRQL-рівнів пристроїв.
- IRQL-рівні пристроїв (device) використовуються для визначення пріоритетів переривань, пов`язаних з пристроями. Порядок відображення рівнів переривань на IRQL-рівні показаний в попередніх статтях.
- Рівень скоригованої машинної перевірки (corrected machine check) використовується для оповіщення операційної системи після серйозної, але скоригованої апаратної несприятливу екологічну ситуацію або помилки, про яку через інтерфейс Machine Check Error (MCE) повідомив центральний процесор або вбудоване програмне забезпечення.
- Рівень відкладеного виклику процедури і диспетчеризації (DPC / dispatch) і рівень асинхронного виклику процедури (APC) відносяться до програмних переривань, що генеруються ядром і драйверами пристроїв. Більш докладно виклики DPC і APC будуть розглянуті пізніше.
- Найнижчий пасивний IRQL-рівень (passive) насправді взагалі не є справжнім рівнем прериваній- він відповідає звичайному виконання потоку і можливості виникнення всіх переривань.
Експеримент: Використання засобу профілювання ядра (Kernrate) для виміру продуктивності
Засіб Kernel Profiler (Kernrate) можна використовувати для включення таймера профілювання системи, збору прикладів коду, виконуваних при запусках таймера, і виведення підсумкової інформації про розподіл процесорного часу між файлами образів завдань і функцій. Воно може бути використано для відстеження часу центрального процесора, споживаного окремими процесами і (або) часу, проведеному в режимі ядра незалежно від процесів (наприклад, витрачений на процедури обслуговування переривання). Профілювання ядра застосовується при необхідності розібратися в тому, на що система витрачає час.
У своїй найпростішій формі Kernrate надає вибірку витрат часу на кожен модуль ядра (наприклад, на Ntoskrnl, драйвери і т. Д.).
Наприклад, після установки Windows Driver Kit спробуйте виконати наступні дії.
- Відкрийте вікно командного рядка.
- Наберіть cd C: WinDDK 7600.16385.1 tools other (шлях до вашої установці WDKдля Windows 7 / Server 2008R2).
- Наберіть dir. Ви побачите каталоги для кожної платформи.
- Запустіть образ, відповідний вашої платформі (без аргументів або ключів). Наприклад, для системи x86 використовується образ i386 kernrate.exe.
- Під час роботи Kernrate виконайте на системі якісь інші дії. Наприклад, запустіть Windows Media Player і програйте якусь музику, запустіть гру, широко використовує графіку, або зробіть що-небудь в мережі на кшталт виведення вмісту каталогу на віддаленому загальному мережевому ресурсі.
- Натисніть Ctrl + C для зупинки Kernrate. Це змусить Kernrate показати статистику за період вибірки.
У наступному виведенні вибірки з Kernrate показано, що був запущений програвач Windows Media Player, який відтворює фільм з диска:
C: WinDDK 7600.16385.1 tools Other i386> kernrate.exe
/ ==============================
< KERNRATE LOG >
============================== /
Date: 2011/03/09 Time: 16:44:24
Machine Name: TEST-LAPTOP
Number of Processors: 2
PROCESSOR_ARCHITECTURE: x86
PROCESSOR_LEVEL: 6
PROCESSOR_REVISION: 0f06
Physical Memory: 3310 MB
Pagefile Total: 7285 MB
Virtual Total: 2047 MB
PageFile1: ?? C: pagefile.sys, 4100MB
OS Version: 6.1 Build 7601 Service-Pack: 1.0
WinDir: C: Windows
Kernrate Executable Location: C: WINDDK 7600.16385.1 TOOLS OTHER I386
Kernrate User-Specified Command Line:
kernrate.exe
Kernel Profile (PID = 0): Source = Time,
Using Kernrate Default Rate of 25000 events / hit
Starting to collect profile data
***> Press ctrl-c to finish collecting profile data
===> Finished Collecting Data, Starting to Process Results
------------Overall Summary: --------------
P0 K 0: 00: 00.000 (0.0%) U 0: 00: 00.234 (4.7%) I 0: 00: 04.789 (95.3%)
DPC 0: 00: 00.000 (0.0%) Interrupt 0: 00: 00.000 (0.0%)
Interrupts = 9254, Interrupt Rate = тисяча вісімсот сорок дві / sec.
P1 K 0: 00: 00.031 (0.6%) U 0: 00: 00.140 (2.8%) I 0: 00: 04.851 (96.6%)
DPC 0: 00: 00.000 (0.0%) Interrupt 0: 00: 00.000 (0.0%)
Interrupts = 7051, Interrupt Rate = 1404 / sec.
TOTAL K 0: 00: 00.031 (0.3%) U 0: 00: 00.374 (3.7%) I 0: 00: 09.640 (96.0%)
DPC 0: 00: 00.000 (0.0%) Interrupt 0: 00: 00.000 (0.0%)
Total Interrupts = 16305, Total Interrupt Rate = 3246 / sec.
Total Profile Time = 5023 msec
BytesStart BytesStop BytesDiff.
Available Physical Memory, 1716359168, 1716195328, -163840
Available Pagefile (s), 5973733376, 5972783104, -950272
Available Virtual, 2122145792, 2122145792, 0
Available Extended Virtual, 0, 0, 0
Committed Memory Bytes, 1665404928, 1666355200, 950272
Non Paged Pool Usage Bytes, 66211840, 66211840, 0
Paged Pool Usage Bytes, 189083648, 189087744, 4096
Paged Pool Available Bytes, 150593536, 150593536, 0
Free System PTEs, 37322, 37322, 0
Total Avg. Rate
Context Switches, 30152, 6003 / sec.
System Calls, 110807, 22059 / sec.
Page Faults, 226, 45 / sec.
I / O Read Operations, 730, 145 / sec.
I / O Write Operations, тисячі тридцять вісім, 207 / sec.
I / O Other Operations, 858, 171 / sec.
I / O Read Bytes, 2013850, 2759 / I / O
I / O Write Bytes, 28212, 27 / I / O
I / O Other Bytes, 19902, 23 / I / O
-----------------------------
Results for Kernel Mode:
-----------------------------
OutputResults: KernelModuleCount = 167
Percentage in the following table is based on the Total Hits for the Kernel
Time 3814 hits, 25000 events per hit --------
Module Hits msec% Total Events / Sec
NTKRNLPA 3768 5036 98% 18705321
NVLDDMKM 12 5036 0% 59 571
HAL 12 5036 0% 59 571
WIN32K 10 5037 0% 49632
DXGKRNL 9 5036 0% 44678
NETW4V32 2 5036 0% 9928
FLTMGR 1 5036 0% 4964
======================= END OF RUN ======================== ==========
=================== NORMALENDOFRUN ==============================
Загальні підсумки показують, що система провела 0,3% часу в режимі ядра, 3,7% в призначеному для користувача режимі, 96,0% в просте, 0,0% на рівні DPC і 0,0% на рівні переривання. Найбільш затребуваним модулем був Ntkrnlpa.exe, ядро для машин з підтримкою розширення фізичної адреси (PhysicalAddressExtension, PAE) або NX. Другим по затребуваності модулем є nvlddmkm.sys, драйвер для відеокарти на машині, що використовується для тестування. У цьому є сенс, оскільки основна активність, що проявляється в системі, виходила від WindowsMediaPlayer, який відправляв ввід-вивід відео на відеодрайвера.
Якщо у вас є файли символів, ви можете розширити окремі модулі і подивитися витрачений час, розбите по іменах функцій. Наприклад, профілювання системи при швидкому перетягуванні вікна по екрану призведе до наступного висновку (який показаний частково):
C: WinDDK 7600.16385.1 tools Other i386> kernrate.exe -z ntkrnlpa -z win32k
/ ==============================
< KERNRATE LOG >
============================== /
Date: 2011/03/09 Time: 16:49:56
Time 4191 hits, 25000 events per hit --------
Module Hits msec% Total Events / Sec
NTKRNLPA 3623 5695 86% 15904302
WIN32K 303 5696 7% 1329880
INTELPPM 141 5696 3% 618855
HAL 61 5695 1% 267778
CDD 30 5696 0% 131671
NVLDDMKM 13 5696 0% 57057
--- Zoomed module WIN32K.SYS (Bucket size = 16 bytes, Rounding Down) --------
Module Hits msec% Total Events / Sec
BltLnkReadPat 34 5696 10% 149 227
memmove 21 5696 6% 92169
vSrcTranCopyS8D32 17 5696 5% 74613
memcpy 12 5696 3% 52668
RGNOBJ :: bMerge 10 5696 3% 43890
HANDLELOCK :: vLockHandle 8 5696 2% 35112
--- Zoomed module NTKRNLPA.EXE (Bucket size = 16 bytes, Rounding Down) --------
Module Hits msec% Total Events / Sec
KiIdleLoop 3288 5695 87% 14433713
READ_REGISTER_USHORT 95 5695 2% 417032
READ_REGISTER_ULONG 93 5695 2% 408252
RtlFillMemoryUlong 31 5695 0% 136084
KiFastCallEntry 18 5695 0% 79016
Другим по затребуваності модулем був Win32k.sys, драйвер системи управління вікнами. Також високе місце в списку було у відеодрайвера і у Cdd.dll, глобального відеодрайвера, використовуваного для теми робочого столу Aero з 3D-прискоренням. Ці результати цілком зрозумілі, оскільки основна активність системи полягала в промальовуванні екрану.
Зауважте, що в розширеному відображенні для Win32k.sys найбільш затребуваними виявилися функції, пов`язані з об`єднанням, копіюванням і переміщенням бітів, основними GDI-операціями для промальовування вікна, перетягуваного по екрану.
Одним з важливих обмежень, що накладаються на код, що виконується на рівні DPC / dispatch або вище, є те, що він не може чекати об`єкт, якщо це вимагає від планувальника вибрати для виконання інший потік, що є неприпустимою операцією, оскільки планувальник при плануванні потоків залежить від програмних переривань DPC-рівня.
Іншим обмеженням є те, що на IRQL-рівні DPC / dispatch або вище може бути доступна тільки непереміщуваними область пам`яті.
Це правило фактично є побічним ефектом першого обмеження, оскільки спроба звернення до нерезидентної пам`яті призводить до помилки звернення до сторінки. При виникненні такої помилки диспетчер пам`яті ініціює дисковий введення-виведення, а потім змушує чекати, поки драйвер файлової системи вважає сторінку з диска.
Це очікування, в свою чергу, змушує планувальник виконати контекстне перемикання (можливо, на потік простою, idle, якщо запуску не очікує ні один користувальницький потік), порушуючи тим самим правило, за яким планувальник не може бути викликаний, оскільки під час читання диска код як і раніше виконується на IRQL-рівні DPC / dispatch або вище.
Ще одна проблема є наслідком того факту, що завершення введення-виведення відбувається на рівні APC_LEVEL, отже, навіть у тих випадках, коли очікування не буде потрібно, введення-виведення ніколи не завершиться, оскільки завершення APC не отримає жодного шансу на виконання.
При порушенні будь-якого з цих двох обмежень відбувається збій системи з кодом аварійного завершення роботи IRQL_NOT_LESS_OR_EQUAL (IRQL не є меншим або рівним) або DRIVER_IRQL_NOT_LESS_OR_EQUAL (IRQL драйвера не є меншим або рівним). Порушення цих обмежень є поширеною помилкою при створенні драйверів пристроїв. Як засіб, що допомагає виявити помилки подібного типу, можна використовувати верифікатор Windows Driver Verifier.
