Об'єкти управління включають об'єкти-примітиви для потоків, переривань, таймерів, синхронізації, профілювання, а також два спеціальні об'єкти для реалізації DPC та APC. Об'єкти DPC (Deferred Procedure Call – відкладений виклик процедури) використовуються для зменшення часу виконання ISR (Interrupt Service Routines – процедура обслуговування переривань), яка запускається по перериванню від пристрою. Обмеження часу, що витрачається на ISR-процедури, скорочує шанси втрати переривання.
Устаткування системи надає перериванням апаратного рівня пріоритету. Процесор також пов'язує рівень пріоритету з виконуваною ним роботою. Процесор реагує лише на ті переривання, які мають більший пріоритет, ніж той, що використовується в даний момент. Нормальний рівень пріоритету (у тому числі рівень пріоритету всього режиму користувача) - це 0. Переривання пристроїв відбуваються з рівнем 3 або вищим, а ISR для переривання пристрою зазвичай виконується з тим же рівнем пріоритету, що і переривання (щоб інші менш важливі переривання не відбувалися під час обробки більш важливого переривання).
Якщо ISR виконується надто довго, то обслуговування переривань нижчого пріоритету буде відкладено, що, можливо, призведе до втрати даних або уповільнить введення-виведення системи. У будь-який момент часу може виконуватися декілька ISR, при цьому кожна наступна ISR буде виникати від переривань з більш високим рівнем пріоритету.
Для зменшення часу обробки ISR виконуються лише критичні операції, такі як запис результатів операцій введення-виведення та повторна ініціалізація пристрою. Подальша обробка переривання відкладається, поки рівень пріоритету процесора не знизиться і не перестане блокувати обслуговування інших переривань. Об'єкт DPC використовується для представлення роботи, що підлягає виконанню, а ISR викликає рівень ядра для того, щоб поставити DPC в список DPC конкретного процесора. Якщо DPC є першим у списку, ядро реєструє спеціальний апаратний запит на переривання процесора з рівнем 2 (на якому NT викликає рівень DISPATCH). Коли завершується остання існуюча ISR, рівень переривання процесора падає нижче 2, і це розблокує переривання для обробки DPC. ISR для переривання DPC обробить кожен із об'єктів DPC (які ядро поставило в чергу).
Методика використання програмних переривань для відкладання обробки переривань є методом зменшення латентності ISR. UNIX та інші системи почали використовувати відкладену обробку у 1970-х роках (для того, щоб упоратися з повільним обладнанням та обмеженим розміром буферів послідовних підключень до терміналів). ISR отримувала від обладнання символи та ставила їх у чергу. Після того, як вся обробка переривань вищого рівня була закінчена, програмне переривання запускало ISR з низьким пріоритетом для обробки символів (наприклад, для реалізації повернення курсору на одну позицію - для цього на термінал посилався символ керування для стирання останнього відображеного символу, і курсор переміщався назад) .
Аналогічним прикладом у сучасній системі Windows може бути клавіатура. Після натискання клавіші клавіатурна ISR читає з регістра код клавіші, а потім знову дозволяє клавіатурне переривання, але не робить обробку клавіші негайно. Натомість вона використовує DPC для встановлення обробки коду клавіші в чергу (до того моменту, поки всі підлягають обробці переривання пристрою не будуть відпрацьовані).
Оскільки DPC працюють на рівні 2, вони не заважають виконанню ISR для пристроїв, але заважають виконувати будь-які потоки до тих пір, поки всі поставлені в чергу DPC не завершаться і рівень пріоритету процесора не впаде нижче 2. Драйвери пристроїв і система не повинні надто довго виконувати ISR чи DPC. Оскільки потокам не дозволяється виконуватися, то ISR і DPC можуть зробити систему повільною і породити збої під час відтворення музики (гальмуючи ті потоки, які пишуть музику з буфера в звуковий пристрій). Інший частий випадок використання DPC – це виконання процедур з переривання таймера. Щоб уникнути блокування потоків події таймера (які повинні виконуватися тривалий час), повинні ставити в чергу запити до пулу робочих потоків (який підтримує ядро для фонової роботи).
Важливою особливістю процедур, що виконуються за запитами переривань, є те, що вони виконують роботу, найчастіше не пов'язану з поточним процесом.
Наприклад, драйвер диска може отримати керування після того, як контролер диска записав у відповідні сектори інформацію, отриману від процесу А, але цей момент часу не збігається з періодом чергової ітерації виконання процесу А або його потоку.
У найбільш типовому випадку процес А перебуватиме в стані очікування завершення операції введення-виведення (при синхронному режимі виконання цієї операції) і драйвер диска перерве будь-який інший процес.
У деяких випадках взагалі важко однозначно визначити, для якого процесу виконує роботу той чи інший програмний модуль ОС, наприклад, планувальник потоків. Тому для таких процедур вводяться обмеження - вони мають права використовувати ресурси (пам'ять, відкриті файли тощо.), із якими працює поточний процес.
Процедури обробки переривань працюють з ресурсами, виділеними ним при ініціалізації відповідного драйвера або ініціалізації самої операційної системи. Ці ресурси належать ОС, а чи не конкретному процесу. Так пам'ять драйверам виділяється із системної області. Тому зазвичай кажуть, що процедури обробки переривання працюють поза контекстом процесу.
Диспетчеризація переривань є важливою функцією ОС і ця функція реалізована практично у всіх мультипрограмних ОС. Як правило, у ОС реалізується дворівневий механізм планування робіт. Верхній рівень планування виконується диспетчером переривань, який розподіляє процесорний час між потоком запитів, що надходять, на переривання різних типів - зовнішніх, внутрішніх і програмних. Процесорний час, що залишився, розподіляється іншим диспетчером - диспетчером потоків, на підставі дисциплін квантування та інших, які ми розглядали.
Системні виклики
Системний виклик дозволяє звернутися до ОС з проханням виконати ту чи іншу дію, оформлену як процедура (або набір процедур) кодового сегмента ОС.
Для прикладного програміста ОС виглядає як якась бібліотека, що реалізує корисні функції, що полегшують управління прикладним завданням або виконання дій, заборонених в режимі користувача, наприклад обмін даними з пристроєм введення-виведення.
Реалізація системних викликів повинна відповідати таким вимогам:
· Забезпечувати перемикання в привілейований режим;
· Мати високу швидкість виклику процедур ОС;
· Забезпечувати однакове звернення до системних викликів для всіх апаратних платформ, на яких працюють ОС;
· Допускати легке розширення набору системних викликів;
· Забезпечувати контроль з боку ОС за коректним використанням системних викликів
У більшості ОС системні виклики обслуговуються за централізованою схемою, що базується на існуванні диспетчера системних викликів.
За будь-якого системного виклику програма виконує програмне переривання з певним і єдиним номером вектора.
Перед виконанням програмного переривання програма передає ОС номер системного виклику. Спосіб передачі залежить від реалізації. Наприклад, номер можна помістити в певний регістр процесора або передати через стек. Також деяким способом передаються аргументи системного виклику, вони можуть збожеволіти як, регістри загального призначення, так і передаватися через стек або масив, оперативної пам'яті.
| … |
| Адреса процедури 21h |
| Адреса процедури 22h |
| Адреса процедури 23h |
| … |
| Адреса диспетчера системних викликів |
| Диспетчер системних викликів |
| Процедура обробки Системного виклику 21h |
| Процедура обробки Системного виклику 22h |
| Процедура обробки Системного виклику 23h |
Після завершення роботи системного виклику керування повертається диспетчеру, при цьому він отримує код завершення цього виклику. Диспетчер відновлює регістри процесора, поміщає в певний регістр код повернення та виконує інструкцію повернення з переривання, яка відновлює непривілейований режим роботи процесора.
Описаний табличний спосіб організації системних викликів прийнято практично у всіх операційних системах. Він дозволяє легко модифікувати склад системних дзвінків, просто додавши до таблиці нову адресу та розширивши діапазон допустимих номерів дзвінків.
ОС може виконувати системні виклики синхронномуабо асинхронномурежими.
Синхронний системний викликозначає, що процес, який зробив такий виклик, припиняється до тих пір, поки системний виклик не виконає всю потрібну роботу . Після цього планувальник переводить процес у стан готовності.
Асинхронний системний викликне призводить до переведення процесу в режим очікування після виконання деяких початкових системних дій, наприклад запуску операції виведення-виводу, управління повертається до прикладного процесу.
Більшість системних дзвінків в ОС є синхронними.
Обробка переривань таймера
Кожен комп'ютер має апаратний таймер або системний годинник, який генерує апаратне переривання через фіксовані інтервали часу. Тимчасовий інтервал між сусідніми перериваннями називається тиком процесора або просто тиком (CPU tick, clock tick). Як правило, системний таймер підтримує кілька значень тиків, але в UNIX це значення зазвичай встановлюється рівним 10 мілісекунд, хоча це значення може відрізнятися для різних версій операційної системи. Більшість систем зберігають це значення у константі HZ, яка визначена у файлі заголовків
Обробник переривань ядра викликається апаратним перериванням таймера, пріоритет якого зазвичай найвищий. Таким чином, обробка переривання має займати мінімальну кількість часу. У випадку, обробник вирішує такі задачи:
1. Оновлення статистики використання процесора для поточного процесу
2. Виконання ряду функцій, пов'язаних із плануванням процесів, наприклад перерахунок пріоритетів та перевірку закінчення тимчасового кванта для процесу
3. Перевірка перевищення процесорної квоти для даного процесу та відправка цього процесу сигналу SIGXCPU у разі перевищення
4. Оновлення системного часу (часу дня) та інших пов'язаних з ним таймерів
5. Обробка відкладених викликів
6. Обробка алармів
7. Пробудження у разі потреби системних процесів, наприклад диспетчера сторінок та свопера
Частина завдань не вимагає виконання на кожному тику. Більшість систем вводять нотацію головного тику (major tick), який відбувається кожні тиків, де залежить від конкретної версії системи. Певний набір функцій виконується лише на головних тиках. Наприклад, робить перерахунок пріоритетів кожні 4 тика, a SVR4 обробляє і проводить пробудження системних процесів раз на секунду МакКузік М. К., Невілл-Ніл Дж. В . FreeBSD: архітектура та реалізація . - М.: КУДИЦЬ-ОБРАЗ, 2006. - 800 с...
Відкладені дзвінки
Відкладений виклик визначає функцію, виклик якої буде здійснено ядром системи через деякий час. Наприклад, у SVR4 будь-яка підсистема ядра може зареєструвати відкладений виклик наступним чином:
int co_ID = timeout(void (*fn)(), caddr_t arg, long delta)
де fn визначає адресу функції, яку необхідно викликати, при цьому їй буде передано аргумент arg, а сам виклик буде зроблено через delta тиків. Ядро здійснює виклик fn() у системному контексті, таким чином функція відкладеного виклику не повинна звертатися до адресного простору поточного процесу (оскільки не має до нього відношення), а також не повинна переходити до стану сну.
Відкладені дзвінки використовуються для виконання багатьох функцій, наприклад:
1. Виконання ряду функцій планувальника та підсистеми керування пам'яттю.
2. Виконує ряд функцій драйверів пристроїв для подій, ймовірність ненастання яких відносно велика. Прикладом може бути модуль протоколу TCP, що реалізує таким чином повторну передачу мережних пакетів по таймауту.
3. Опитування пристроїв, які не підтримують переривання.
Зауважимо, що функції відкладених дзвінків виконуються у системному контексті, а чи не у контексті переривання. Виклик цих функцій виконується не обробником таймера, а окремим обробником відкладених дзвінків, який запускається після обробки переривання таймера. При обробці переривання таймера система перевіряє необхідність запуску тих чи інших функцій відкладеного дзвінка та встановлює відповідний прапор для них. У свою чергу обробник відкладених викликів перевіряє прапори та запускає необхідні в системному контексті МакКузік М. К., Невілл-Ніл Дж. В. FreeBSD: архітектура та реалізація. - М.: КУДИЦЬ-ОБРАЗ, 2006. - 800 с...
Контекст процесу
Контекст процесу включає вміст адресного простору завдання, виділеного процесу, а також вміст відносяться до процесу апаратних регістрів і структур даних ядра. З формальної точки зору, контекст процесу поєднує в собі контекст користувача, регістровий контекст і системний контекст.
Користувальницький контекст складається з команд і даних процесу, стека завдання та вмісту спільно пам'яті, що використовується, пам'яті у віртуальних адресах процесу. Ті частини віртуального адресного простору процесу, які періодично відсутні в оперативній пам'яті внаслідок вивантаження або заміщення сторінок, також включаються до контексту користувача.
Реєстровий контекст складається з наступних компонентів:
1. Лічильник команд, що вказує адресу наступної команди, яку виконуватиме центральний процесор; ця адреса є віртуальною адресою всередині простору ядра або простору задачі.
2. Реєстр стану процесора (PS), який вказує апаратний статус машини по відношенню до процесу. Регістр PS, наприклад, зазвичай містить підполя, які вказують, чи є результат останніх обчислень нульовим, позитивним або негативним, чи переповнений регістр з установкою біта переносу і т. д. Операції, що впливають на встановлення регістра PS, виконуються для окремого процесу, тому- то в регістрі S і міститься апаратний статус машини по відношенню до процесу. В інших підполях регістра PS, що мають важливе значення, вказується поточний рівень переривання процесора, а також поточний і попередній режими виконання процесу (режим ядра/завдання). За значенням підполя поточного режиму виконання процесу встановлюється, чи може виконувати привілейовані команди і звертатися до адресного простору ядра.
3. Вказівник вершини стека, в якому міститься адреса наступного елемента стека ядра або стека завдання, відповідно до режиму виконання процесу. Залежно від архітектури машини вказівник вершини стека вказує на наступний вільний елемент стека або останній використовуваний елемент. Від архітектури машини також залежить напрям збільшення стека (до старших чи молодших адрес), але зараз ці питання несуттєві.
4. Реєстрів загального призначення, у яких міститься інформація, що згенерована процесом під час його виконання.
Системний контекст процесу має «статичну частину» (перші три елементи в списку нижче) і «динамічну частину» (останні два елементи). Протягом усього часу виконання процес має одну статичну частину системного контексту, але може мати змінне число динамічних частин. Динамічну частину системного контексту можна подати у вигляді стека, елементами якого є контекстні рівні, які поміщаються в стек ядром або виштовхуються зі стека при настанні різних подій. Системний контекст включає наступні компоненти:
1. Запис у таблиці процесів, що описує стан процесу (розділ 6.1) та містить різну керуючу інформацію, до якої ядро завжди може звернутися.
2. Частина адресного простору завдання, виділена процесу, де зберігається інформація про процес, що управляє, доступна тільки в контексті процесу. Загальні параметри керування, такі як пріоритет процесу, зберігаються в таблиці процесів, оскільки звернення до них повинно проводитися за межами контексту процесу.
3. Записи приватної таблиці областей процесу, загальні таблиці областей і таблиці сторінок, необхідні перетворення віртуальних адрес у фізичні, у зв'язку з ніж у яких описуються області команд, даних, стека та інші області, що належать процесу. Якщо кілька процесів спільно використовують спільні області, ці області входять складовою у контекст кожного процесу, оскільки кожен процес працює з цими областями незалежно від інших процесів. У завдання керування пам'яттю входить ідентифікація ділянок віртуального адресного простору процесу, що не є резидентними в пам'яті.
4. Стек ядра, де зберігаються записи процедур ядра, якщо процес виконується як ядра. Незважаючи на те, що всі процеси користуються одними і тими ж програмами ядра, кожен з них має власну копію стека ядра для зберігання індивідуальних звернень до функцій ядра. Нехай, наприклад, один процес викликає функцію creat і зупиняється в очікуванні призначення нового індексу, а інший процес викликає функцію read і зупиняється в очікуванні завершення передачі даних з диска на згадку. Обидва процеси звертаються до функцій ядра і в кожного з них є окремий стек, в якому зберігається послідовність виконаних звернень. Ядро повинно мати можливість відновлювати вміст стека ядра та положення вказівника вершини стека для того, щоб відновлювати виконання процесу в режимі ядра. У різних системах стек ядра часто розташовується у просторі процесу, проте цей стек є логічно-незалежним і, таким чином, може розміщуватися в самостійній області пам'яті. Коли процес виконується як завдання, відповідний йому стек ядра порожній.
5. Динамічна частина системного контексту процесу, що складається з кількох рівнів і має вигляд стека, що звільняється від елементів у порядку, зворотному порядку їх надходження. На кожному рівні системного контексту міститься інформація, необхідна для відновлення попереднього рівня і включає регістровий контекст попереднього рівня.
Ядро поміщає контекстний рівень у стік у разі переривання, при зверненні до системної функції чи перемиканні контексту процесу. Контекстний рівень виштовхується зі стека після завершення обробки переривання, повернення процесу в режим завдання після виконання системної функції, або при перемиканні контексту. Таким чином, перемикання контексту тягне за собою як приміщення контекстного рівня у стек, так і вилучення рівня зі стеку: ядро поміщає у стек контекстний рівень старого процесу, а витягує зі стека контекстний рівень нового процесу. Інформація, необхідна відновлення поточного контекстного рівня, зберігається у записи таблиці процесів Робачевский А. М. Операційна система UNIX . - СПб.: БХВ - Петербург , 2002. -- 528 з . .
Коли виконується програмний код режиму ядра, пріоритет якого має найбільше значення, ніякий інший код на даному процесорі стартувати не може. Зрозуміло, якщо надто великі обсяги програмного коду будуть виконуватися при занадто високих значеннях IRQL, це неминуче призведе до загальної деградації системи.
Для вирішення такого типу проблем програмний код, призначений для роботи в режимі ядра, повинен бути сконструйований таким чином, щоб уникати тривалої роботи при підвищених рівнях IRQL. Одним із найважливіших компонентів цієї стратегії є Deferred Procedure Calls (DPC) — відкладені процедурні виклики.
Функціонування DPC
Схема застосування відкладених процедурних викликів дозволяє побудувати процес виконання таким чином, що завдання може бути заплановано кодом, що працює на високому рівні IRQL, але вона ще не виконується . Така відстрочка виконання застосовна, якщо здійснюється обслуговування переривання драйвером, і при цьому немає жодних причин блокувати виконання іншого програмного коду нижчого рівня IRQL. Іншими словами — коли обробка цієї ситуації може бути безболісно перенесена на пізніший час.
Для обліку заявок на виклик DPC процедур операційна система підтримує чергу об'єктів DPC.
Для початку обмежимося розглядом більш простого випадку роботи з DPC процедурами, призначеними для використання спільно з процедурами обробки переривань. Цей тип DPC процедур отримав у літературі спеціальну назву DpcForIsr.
Об'єкт DPC для використання у процедурах обробки переривань створюється за викликом IoInitializeDpcRequest, що виконується зазвичай у стартових процедурах драйвера. Даний виклик реєструє запропоновану драйвером DpcForIsr процедуру і асоціює її з об'єктом, що створюється - досить поширена методика в Windows. Слід особливо відзначити, що DPC об'єкт, створений даним викликом, так і залишиться в надрах операційної системи, недоступним розробнику драйвера. (Відмінність DpcForIsr від інших процедур DPC полягає тільки в тому, що робота з останніми проходить за допомогою викликів Ke...Dpc, а створювані для них DPC об'єкти доступні розробнику драйвера.)
Якщо драйвер зареєстрував свою процедуру DpcForIsr, то під час обробки переривання ISR процедурою в системну чергу DPC може бути поміщений відповідний DPC об'єкт (фактично запит на виклик цієї DpcForIsr процедури пізніше) — за допомогою виклику IoRequestDpc. Процедура DpcForIsr завершить пізніше обробку отриманого ISR процедурою запиту, що буде виконано в менш критичних умовах і за низького рівня IRQL.
Загалом, функціонування DPC процедур (в даному випадку, DpcForIsr) складається з наступних операцій:
- Коли деякий фрагмент програмного коду, що працює на високому (апаратному) рівні IRQL бажає запланувати виконання частини своєї роботи так, щоб вона була виконана при низькому значенні IRQL, він додає DPC об'єкт в системну чергу відкладених процедурних викликів.
- Рано чи пізно значення IRQL процесора падає нижче DISPATCH_LEVEL, і робота, яка була відкладена перериванням, обслуговується DPC функцією. Диспетчер DPC витягує кожен DPC об'єкт із черги та викликає відповідну функцію, вказівник на яку зберігається в цьому об'єкті. Виклик цієї функції виконується, коли процесор працює на рівні DISPATCH_LEVEL.
Особливості механізму DPC
Як правило, робота з відкладеними процедурними викликами не є складною, оскільки операційні системи Windows 2000/XP/Server 2003 пропонують великий набір системних викликів, що приховують більшу частину деталей цього процесу. Тим не менш, особливо слід виділити два найбільш оманливі моменти у роботі з DPC.
По-перше, Windows NT 5 встановлює обмеження, що полягає в тому, що один екземпляр об'єкта DPC може бути поміщений в системну DPC чергу в певний часовий проміжок. Спроби помістити в чергу DPC об'єкт, що точно збігається з вже там присутнім, відкидаються. В результаті відбувається лише один виклик DPC процедури, навіть якщо драйвер очікує виконання двох викликів. Це може статися, якщо два переривання були викликані пристроєм, що обслуговується, а обробка першого відкладеного процедурного виклику ще не починалася. Перший екземпляр DPC об'єкта ще перебуває у черзі, тоді як драйвер вже приступив до обробки другого переривання.
Конструкція драйвера повинна передбачати такий процес роботи DPC механізму. Можливо, слід передбачити додатково лічильник DPC запитів або драйвер може реалізувати власну реалізацію черги запитів. У момент виконання реальної відкладеної процедури можна перевіряти лічильник та власну чергу запитів для того, щоб визначити, яку роботу слід виконувати.
По-друге, існують значні синхронізаційні проблеми під час роботи на багатопроцесорних платформах. Припустимо, програмний код, що виконується на одному процесорі, виконує обслуговування переривання та планує виклик DPC процедури (розміщуючи DPC об'єкт у системній черзі). Тим не менш, ще до моменту повного завершення обробки переривання інший процесор може почати обробку DPC об'єкта, поміщеного в системну чергу. Таким чином виникає ситуація, в якій програмний код обслуговування переривань виконується паралельно і одночасно з кодом DPC процедури. З цієї причини необхідно передбачити заходи щодо надійної синхронізації доступу програмного коду DPC процедури до ресурсів, які використовуються разом із драйверною процедурою обслуговування переривання.
Якщо переглянути список параметрів дзвінків IoInitializeDpcRequestі IoRequestDpc(призначені для роботи з DpcForIsr процедурами), то неважко помітити, що DPC об'єкт "прив'язаний" до об'єкта пристрою. При розміщенні цього об'єкта в DPC черзі в момент роботи ISR процедури також вказується об'єкт пристрою. Цим і досягається визначеність, виклик якої конкретно DPC процедури "замовлено" ISR процедурою (співвіднесення об'єкта пристрою). Це говорить про те, що драйвер, який створив кілька об'єктів пристроїв (досить рідкісний випадок), може експлуатувати і кілька процедур DpcForIsr - по одній для кожного об'єкта пристрою.
Системний DPC механізм запобігає можливості одночасної обробки DPC об'єктів із системної черги, навіть в умовах багатопроцесорної конфігурації. Таким чином, якщо ресурси використовуються разом декількома відкладеними процедурами, то немає необхідності дбати про синхронізацію доступу до них.
| Вище було розглянуто використання процедур DPC для завершення обробки переривань, тобто DpcForIsr. Однак процедури DPC можна використовувати і в іншому ключі, наприклад, спільно з таймерами для організації очікування. Для цього створиться об'єкт DPC за допомогою дзвінка KeInitializeDPC, який пов'язує цей об'єкт з процедурою DPC, що входить до складу драйвера. Після цього можна виконувати встановлення часу очікування в попередньо ініціалізованому (використовуючи KeInitializeTimerабо KeInitializeEx) об'єкт таймера. Для встановлення інтервалу очікування використовується дзвінок KeSetTimer, якому як один з параметрів необхідно передати покажчик на ініціалізований DPC об'єкт. Після закінчення інтервалу очікування DPC об'єкт буде внесений до системної DPC черги, і DPC процедура, асоційована з ним, буде викликана так швидко, наскільки це буде можливо. Процедури DPC цього, другого типу позначені в документації DDK терміном "Custom DPC". (Цей варіант використання DPC процедур робить їх дуже нагадують APC виклики користувача режиму.) |
Для розміщення у системній DPC черзі об'єктів, що відповідають другому типу DPC процедур (не пов'язаних із перериваннями), слід використовувати виклик KeInsertQueueDpc. Відповідно, код-ініціатор виклику повинен працювати на рівні IRQL не нижче DISPATCH_LEVEL.
Для очищення системної DPC черги від Custom DPC процедур, наприклад, якщо драйвер повинен терміново завершити роботу, призначений виклик KeRemoveQueueDpcякий може бути викликаний з коду будь-якого рівня IRQL.
Найпоширенішою проблемою операційної системи Windows будь-якої редакції є завантаження ресурсів комп'ютера «внутрішніми» процесами. Одним із таких процесів є системне переривання, яке може серйозно навантажувати ресурси комп'ютера, що відображатиметься у «Диспетчері завдань». Найчастіше доводиться зіштовхуватися із ситуацією, коли системне переривання вантажить процесор, через що комп'ютер серйозно втрачає у продуктивності. У рамках цієї статті ми розглянемо, чому це відбувається, і чи можна відключити системні переривання Windows.
Системні переривання: що це за процес
Процес «Системні переривання» за промовчанням в операційній системі Windows запущений постійно, але при звичайній роботі не повинен навантажувати компоненти системи більш ніж на 5%. Якщо цей процес більш серйозно впливає на ресурси комп'ютера, це говорить про наявність апаратної проблеми, а саме порушення в роботі одного з компонентів комп'ютера.
Коли «Системні переривання» вантажать процесор, це може сигналізувати про проблеми в роботі відеокарти, материнської плати, оперативної пам'яті чи іншого елемента системного блоку. Центральний процесор намагається доповнити недостатню потужність, що виникла через неправильну роботу компонента, за допомогою власних ресурсів, про що свідчить процес «Системні переривання». Найчастіше проблема неправильної роботи компонентів комп'ютера пов'язана з повною або частковою несумісністю запущеної програми (або гри) із драйверами компонентів комп'ютера.
Як вимкнути системні переривання
Як було зазначено вище, системні переривання є не більше, ніж покажчиком, що з боку Windows йде додаткове звернення до ресурсів центрального процесора. Вимкнути системні переривання, щоб підвищити продуктивність комп'ютера, не вдасться, і потрібно шукати проблему в роботі компонентів PC. Для цього зручно використовувати програму DPC Latency Checker, яку можна завантажити безкоштовно в інтернеті з сайту розробників. Програма дозволяє визначити несправні компоненти комп'ютера.
Щоб провести діагностику системи програмою DPC Latency Checker, запустіть його та зачекайте. Певний час піде на перевірку комп'ютера, після чого користувач побачить на графіку, якщо проблеми в роботі компонентів системи. Також програма вкаже на можливі помилки та порадить їх пошукати, відключаючи пристрої.
Для цього перейдіть в "Диспетчер пристроїв", натиснувши правою кнопкою миші на "Пуск" і вибравши відповідний пункт, і почніть по одному відключати пристрої. Після кожного відключення перевіряйте в «Диспетчері завдань» та програмі DPC Latency Checker, чи усунуто проблеми із завантаженням процесора системними перериваннями. Якщо проблема залишилася, увімкніть пристрій назад і перейдіть до наступного.
Важливо:Під час вимкнення компонентів у диспетчері пристроїв не відключайте комп'ютер, процесор і системні пристрої, інакше це призведе до екстреного перезавантаження комп'ютера.
Коли знайдено пристрій, при відключенні якого навантаження на процесор знизиться до нормального стану, оновіть драйвера для цього компонента з офіційного сайту розробників.
Зверніть увагу:Якщо були спроби вимкнути всі компоненти системи, але процес «Системні переривання» продовжує навантажувати систему, спробуйте оновити драйвера для процесора.
У ситуації, коли наведені вище поради не допомагають впоратися з проблемою завантаження процесора системними перериваннями, можна випробувати ще такі способи виправлення ситуації:
Варто відзначити, що відключати системні переривання через «Диспетчер завдань» не слід, це призведе до збою системи, але не вирішить проблему.
