IRQ – co to jest i jak zarządzać przerwaniami?

IRQ to żądanie przerwania – sygnał wysyłany do procesora przez urządzenia sprzętowe (np. dysk, karta sieciowa, klawiatura), który wymusza natychmiastową reakcję CPU i zmianę aktualnie wykonywanego kodu.

Dzięki przerwaniom komputer potrafi obsługiwać wiele urządzeń równocześnie i reagować na zdarzenia w czasie rzeczywistym.

Poniżej znajdziesz rozbudowany, ponadczasowy poradnik: od podstaw działania IRQ, przez praktyczne zarządzanie przerwaniami w Windows i Linuksie, aż po wskazówki dla programistów sterowników.

Czym jest przerwanie i IRQ?

Definicja przerwania

Przerwanie (interrupt, żądanie przerwania) to sygnał, który powoduje zmianę przepływu sterowania programu – procesor przestaje wykonywać bieżący kod i natychmiast przechodzi do specjalnej procedury obsługi przerwania.

Przerwanie jest zdarzeniem asynchronicznym: może wystąpić w dowolnym momencie, niezależnie od tego, co aktualnie robi procesor. Typowy przykład to zakończenie operacji wejścia/wyjścia (I/O), wykrycie błędu, naciśnięcie klawisza na klawiaturze czy przyjście pakietu sieciowego.

Co oznacza skrót IRQ?

IRQ (Interrupt ReQuest) to zarówno nazwa samego żądania przerwania – sygnału zgłaszanego do procesora przez urządzenie, jak i nazwa linii przerwania w klasycznym PC („interrupt request line”), do której podłączone są urządzenia sprzętowe.

Każdej linii IRQ przypisany jest unikatowy numer (np. IRQ 0, IRQ 1, IRQ 14), który identyfikuje źródło przerwania. Dzięki temu system operacyjny wie, który sterownik powinien obsłużyć dane przerwanie.

Maskowalne i niemaskowalne przerwania

IRQ to przerwania maskowalne – procesor może je tymczasowo zablokować (zamaskować), jeśli dany fragment kodu musi być chroniony przed przerwaniem.

NMI (Non-Maskable Interrupt) to przerwanie niemaskowalne, którego procesor nie może zignorować – używane do sygnałów krytycznych, np. poważnych błędów sprzętowych.

IRQ jest „grzeczną prośbą o przerwanie”, którą CPU może chwilowo odroczyć, w odróżnieniu od NMI, które musi zostać obsłużone natychmiast.

Jak działa mechanizm przerwań w komputerze?

Normalna praca procesora i „wejście” przerwania

Procesor wykonuje ciąg instrukcji wyznaczony przez aktualny program – system operacyjny i aplikacje. Gdy urządzenie sprzętowe potrzebuje uwagi CPU (np. zakończyło transfer danych), wysyła sygnał IRQ do kontrolera przerwań.

W uproszczeniu przebieg jest następujący:

1. Urządzenie (np. karta sieciowa, dysk) generuje sygnał IRQ na przypisanej linii przerwania.
2. Programowalny kontroler przerwań (PIC/APIC) odbiera sygnał, ustala numer przerwania i informuje o nim procesor.
3. Procesor zatrzymuje aktualne zadanie, zapisuje swój stan (rejestry, licznik programu) i przechodzi do procedury obsługi przerwania (ISR – Interrupt Service Routine).
4. Sterownik urządzenia wykonuje potrzebne operacje (np. odczyt danych z bufora, aktualizacja struktur systemu).
5. Sterownik lub kontroler przerwań wysyła sygnał zakończenia przerwania (End Of Interrupt), po czym procesor wraca do poprzedniego zadania.

Mechanizm przerwań sprawia, że CPU nie musi „odpyt ywać” urządzeń (polling), lecz reaguje tylko wtedy, gdy coś się wydarzy – to znacznie zwiększa wydajność.

Kontroler przerwań (PIC, APIC)

Między urządzeniami a procesorem znajduje się programowalny kontroler przerwań (PIC – Programmable Interrupt Controller), który realizuje kluczowe zadania:

• ma określoną liczbę linii IRQ (w klasycznym PC – 16, od IRQ 0 do IRQ 15),
• przypisuje numery przerwań do urządzeń i ustala ich priorytety,
• decyduje, które przerwanie ma zostać obsłużone jako pierwsze, jeśli zgłoszeń jest kilka jednocześnie.

W nowoczesnych systemach rolę tę pełnią rozbudowane kontrolery APIC (Advanced Programmable Interrupt Controller), obsługujące wiele rdzeni CPU i bardziej złożone mapowanie przerwań.

Rodzaje przerwań

Przerwania sprzętowe

Przerwanie sprzętowe to przerwanie wywołane przez urządzenie wejścia/wyjścia (I/O), np. kontroler dysku, kartę sieciową, kontroler USB czy klawiaturę.

Typowe zastosowania przerwań sprzętowych obejmują:

• zakończenie operacji odczytu/zapisu danych z dysku,
• przyjście pakietu sieciowego,
• naciśnięcie klawisza na klawiaturze lub ruch myszy,
• sygnał zegara systemowego (odmierzanie czasu systemowego),
• zgłoszenie błędu sprzętowego.

W dokumentacji często używa się określenia „IRQ” właśnie w kontekście przerwań sprzętowych.

Przerwania programowe i wyjątki

Oprócz przerwań sprzętowych istnieją także przerwania wyzwalane przez kod: przerwania programowe (uruchamiane specjalną instrukcją CPU, m.in. do wywołań systemowych) oraz wyjątki (exceptions) – generowane przez sam procesor w sytuacjach szczególnych, np. dzielenie przez zero lub dostęp do nieistniejącej pamięci.

Klasyczna mapa IRQ w PC – kto używa którego numeru?

W tradycyjnych komputerach PC z magistralą ISA/PCI istniała dość stała mapa numerów IRQ przypisana do typowych urządzeń. Poniżej najważniejsze przypisania:

• IRQ 0 – zegar systemowy (timer), odmierza tik systemowy;
• IRQ 1 – klawiatura;
• IRQ 2 – kaskada drugiego kontrolera przerwań (łączenie dwóch PIC);
• IRQ 3, IRQ 4 – porty szeregowe (COM1, COM2);
• IRQ 5, IRQ 7 – urządzenia dodatkowe (np. karty dźwiękowe, drukarki LPT w klasycznych konfiguracjach);
• IRQ 8 – zegar czasu rzeczywistego (RTC);
• IRQ 12 – mysz PS/2;
• IRQ 14 – pierwszy kontroler IDE (pierwszy dysk twardy);
• IRQ 15 – drugi kontroler IDE (dodatkowe dyski/napędy).

W nowoczesnych komputerach ta mapa jest bardziej elastyczna: urządzenia PCI/PCIe mogą dzielić linie IRQ, a wiele z nich korzysta z przerwań w formie komunikatów (MSI/MSI-X) zamiast klasycznych linii – mapowanie odbywa się w warstwie programowej kontrolera przerwań.

IRQ a nowoczesne magistrale – PCI, PCIe, USB

Udostępnianie („sharing”) IRQ przez urządzenia PCI

W magistrali PCI wiele urządzeń może współdzielić tę samą linię przerwania IRQ – kontroler i system operacyjny rozstrzygają, które urządzenie faktycznie zgłosiło przerwanie.

Zasada działania wygląda następująco:

• każde urządzenie PCI może być logicznie przypisane do jednego z kilku „wewnętrznych” sygnałów IRQ magistrali,
• te sygnały są następnie mapowane na linie kontrolera przerwań (PIC/APIC),
• gdy przerwanie pojawia się na danej linii, sterowniki urządzeń współdzielących ten IRQ sprawdzają, czy to ich zdarzenie, i tylko właściwy sterownik je obsługuje.

Windows obsługuje mechanizmy PCI IRQ Steering, które automatycznie konfigurują mapowanie przerwań PCI i ich współdzielenie. W starszych systemach (np. Windows 9x/Me) można było sprawdzić kompatybilność tej funkcji w ustawieniach magistrali PCI i zakładce sterowania przerwaniami.

Przerwania w USB, PCIe, MSI/MSI-X

Nowoczesne urządzenia PCI Express często korzystają z mechanizmu MSI (Message Signaled Interrupts), gdzie przerwanie nie jest sygnałem na fizycznej linii, lecz specjalnym zapisem do przestrzeni adresowej kontrolera APIC – to uelastycznia konfigurację i ułatwia skalowanie na wiele rdzeni CPU.

Dla użytkownika w praktyce nadal mówimy o „IRQ”, choć technicznie coraz częściej chodzi o logiczne identyfikatory przerwań przypisane do urządzeń.

Przerwania w systemach operacyjnych

IRQ w Linuksie

W Linuksie przerwanie sprzętowe traktowane jest jako sygnał asynchroniczny, informujący jądro o zdarzeniach wymagających natychmiastowej reakcji (zakończenie I/O, błąd itp.). Aby system reagował na przerwania, kernel musi zarejestrować procedurę obsługi dla danej linii IRQ:

• istnieje skończona liczba linii przerwań (np. 16 w klasycznym i386),
• dla każdej z nich jądro rejestruje funkcję, która ma być wywołana, gdy IRQ się pojawi,
• sterownik urządzenia współpracuje z tym mechanizmem, zgłaszając przerwania i obsługując je w zarejestrowanej procedurze.

W Linuksie wyróżnia się zwykle dwie fazy obsługi przerwania (top half i bottom half): krótki, minimalny kod wykonywany natychmiast po przerwaniu oraz dalszą pracę odroczoną, aby nie blokować zbyt długo CPU.

IRQ w Windows

Windows zarządza przerwaniami poprzez własny kontroler abstrakcji sprzętu i sterowniki. W starszych wersjach systemu (Windows XP/Vista, 9x/Me) konfiguracja IRQ była dla użytkownika bardziej „widoczna” – można ją było sprawdzić m.in. w msinfo32 (zasoby sprzętowe → przerwania) oraz we właściwościach magistrali PCI (zakładka sterowania przerwaniami, PCI IRQ Steering).

W nowszych Windows mapowanie przerwań jest w dużej mierze zarządzane automatycznie przez ACPI, BIOS/UEFI i system – użytkownik może głównie włączać/wyłączać urządzenia i modyfikować ustawienia w BIOS/UEFI, a nie ręcznie przypisywać numery IRQ.

Zarządzanie przerwaniami z perspektywy użytkownika i administratora

Choć nowoczesne systemy operacyjne w dużej mierze automatyzują konfigurację IRQ, świadome zarządzanie przerwaniami nadal ma znaczenie – szczególnie w sytuacjach takich jak:

• problemy ze stabilnością (zawieszanie się sterowników, „zamrażanie” systemu),
• optymalizacja pod niski czas reakcji (audio na żywo, produkcja muzyczna, gry, systemy czasu rzeczywistego),
• serwery obsługujące wiele intensywnie pracujących urządzeń (macierze dysków, bardzo szybkie sieci).

Sprawdzanie przypisanych IRQ

Windows (XP i podobne): uruchom msinfo32, a następnie przejdź do sekcji „zasoby sprzętowe” → „przerwania”, aby zobaczyć listę urządzeń i przypisanych im numerów IRQ.

Linux: użyj cat /proc/interrupts – zobaczysz listę linii przerwań, liczbę ich wystąpień oraz przypisane sterowniki i CPU obsługujące dane IRQ; to ułatwia wykrycie urządzeń generujących najwięcej przerwań i ewentualnej „burzy przerwań”.

Wyłączanie nieużywanych urządzeń

Jeżeli chcesz zapewnić jak najwięcej zasobów systemu dla konkretnych zadań (np. audio), rozważ wyłączenie urządzeń, których nie używasz: w BIOS/UEFI (np. nieużywane porty COM/LPT, zintegrowane kontrolery) oraz w systemie (menedżer urządzeń – wyłączenie lub odinstalowanie zbędnych sterowników).

Przynosi to wymierne efekty:

• mniej urządzeń zgłaszających przerwania,
• mniejsze ryzyko drobnych konfliktów sterowników,
• często niższe opóźnienia (latency) w krytycznych zastosowaniach audio/wideo.

Optymalizacja pod kątem audio w Windows

W produkcji muzycznej na PC kluczowa jest ciągłość i stabilność obsługi przerwań przez urządzenia audio (karty dźwiękowe, kontrolery USB/FireWire, interfejsy zewnętrzne). Przydatne zalecenia obejmują:

• zlokalizowanie urządzenia audio lub kontrolera (USB/FireWire) i sprawdzenie przypisanego mu IRQ,
• wyłączenie zbędnych urządzeń (np. nieużywane porty, dodatkowe kontrolery, sieć – jeśli niepotrzebna w sesji),
• używanie aktualnych, stabilnych sterowników audio zgodnych z mechanizmami przerwań.

Tuning IRQ w Linuksie

Na serwerach i maszynach wielordzeniowych warto stosować przypisywanie przerwań do konkretnych rdzeni (IRQ affinity) oraz separację zadań czasu rzeczywistego od intensywnej obsługi przerwań (np. sieci, dysków). Konfigurację wykonasz przez parametry w /proc i /sys dla danego IRQ, m.in. smp_affinity.

Efekty takiego podejścia:

• lepsze wykorzystanie wielu rdzeni,
• mniejsza konkurencja między kluczowymi zadaniami a obsługą „hałaśliwych” urządzeń,
• stabilniejszy czas reakcji w aplikacjach czasu rzeczywistego.

Zarządzanie przerwaniami z perspektywy programisty

Jeżeli tworzysz sterowniki urządzeń lub pracujesz w niskopoziomowej warstwie systemu, zrozumienie IRQ jest kluczowe – od jakości kodu obsługi przerwań zależy stabilność całego systemu.

Rejestrowanie procedury obsługi przerwania

W systemach takich jak Linux, programista sterownika powinien:

• określić, z jakiej linii IRQ korzysta urządzenie (np. odczyt z konfiguracji sprzętu/PCI),
• zarejestrować procedurę obsługi przerwania (ISR) w jądrze – przypisać funkcję do konkretnego numeru IRQ,
• włączyć przerwania po stronie urządzenia (ustawić odpowiednie bity w jego rejestrach).

Gdy urządzenie zgłasza przerwanie, przebieg jest standardowy:

• kontroler przekazuje zgłoszenie do procesora,
• CPU uruchamia zarejestrowaną procedurę obsługi,
• sterownik odczytuje dane, czyści flagi w urządzeniu i zgłasza zakończenie obsługi.

Zasady pisania dobrych ISR

Dobra procedura obsługi przerwania powinna spełniać kilka zasad:

• być jak najkrótsza – nie wykonywać długotrwałych operacji, aby nie blokować CPU i innych przerwań,
• nie korzystać z funkcji mogących usypiać wątek lub czekać na I/O (w Linuksie wiele takich funkcji jest zabronionych w kontekście przerwania),
• szybko potwierdzać obsługę przerwania w urządzeniu, aby uniknąć dodatkowych, zbędnych zgłoszeń,
• delegować cięższe operacje do późniejszej fazy – „dolnej połówki”, taskletów, workqueue, DPC (w Windows) – zgodnie z architekturą systemu.

Nieprzemyślane ISR mogą powodować poważne problemy:

• spadki wydajności,
• „burze przerwań” (IRQ storm), gdy urządzenie zgłasza przerwania szybciej, niż system potrafi je obsłużyć,
• zawieszanie się systemu, jeśli przerwanie nie zostanie prawidłowo wyczyszczone.

Maskowanie i priorytety przerwań

W niektórych sytuacjach programista może maskować przerwania – tymczasowo wyłączać ich obsługę, aby wykonać krytyczny fragment kodu bez ryzyka przerwania.

Kontroler przerwań utrzymuje także priorytety – niektóre przerwania są obsługiwane wcześniej niż inne (np. zegar systemowy, błędy sprzętowe vs. urządzenia peryferyjne).

Świadome zarządzanie maskowaniem i priorytetami jest konieczne zwłaszcza w:

• systemach wbudowanych,
• systemach czasu rzeczywistego,
• sterownikach krytycznych (np. urządzenia medyczne, sieci w infrastrukturze o wysokiej dostępności).

Najczęstsze problemy związane z IRQ i praktyczne wskazówki

„Burza przerwań” (IRQ storm)

„Burza przerwań” występuje, gdy urządzenie generuje bardzo dużo przerwań w krótkim czasie – szybciej, niż sterownik jest w stanie je obsłużyć.

Skutki takiej sytuacji:

• wysokie użycie CPU,
• spadki wydajności systemu,
• możliwe zawieszanie się systemu (gdy obsługa przerwań blokuje inne zadania).

Najczęstsze rozwiązania obejmują:

• aktualizację sterownika,
• zmianę konfiguracji urządzenia (np. rozmiaru bufora, trybu pracy),
• w systemach serwerowych – rozłożenie przerwań na wiele rdzeni (IRQ affinity).

Konflikty IRQ i współdzielenie przerwań

W starszych systemach (BIOS bez ACPI, Windows 9x, klasyczne ISA) urządzenia mogły wchodzić w konflikt, gdy dwa urządzenia wymagały wyłącznego użycia tego samego IRQ – prowadziło to do zawieszania się sterowników, błędów I/O i niestabilności. W nowoczesnych systemach (ACPI, PCI/PCIe, nowsze Windows, Linux) stosuje się współdzielenie IRQ i logikę rozstrzygania źródła przerwania, ale nadal warto unikać nadmiernego obciążania jednej linii przez wiele intensywnie pracujących urządzeń; przy problemach ze stabilnością pomocna bywa zmiana slotu PCIe lub korekta ustawień w BIOS/UEFI, aby uzyskać inne mapowanie przerwań.

Opóźnienia w audio i wideo

W zastosowaniach audio i wideo kluczowe są maksymalne opóźnienia (latency) w obsłudze przerwań, a nie tylko średnie czasy.

Zbyt długie opóźnienia w obsłudze przerwań od karty audio lub kontrolera USB mogą skutkować:

• trzaskami i „glitchami” w dźwięku,
• gubieniem ramek wideo,
• niestabilnością przy bardzo małych buforach (np. nagrywanie wielośladowe, występy na żywo).

Aby ograniczyć problem, warto:

• wyłączyć zbędne urządzenia generujące przerwania,
• używać sterowników zoptymalizowanych pod niskie opóźnienia,
• monitorować opóźnienia DPC/ISR za pomocą dedykowanych narzędzi.