Przerwij burzę

W systemach operacyjnych burza przerwań to zdarzenie, podczas którego procesor otrzymuje nadmierną liczbę przerwań , które pochłaniają większość czasu procesora. Burze przerwań są zwykle powodowane przez urządzenia sprzętowe, które nie obsługują ograniczania częstotliwości przerwań.

Tło

Ponieważ przetwarzanie przerwań w systemach operacyjnych z podziałem czasu jest zwykle zadaniem, którego nie można wywłaszczać , burza przerwań spowoduje powolną reakcję na dane wprowadzane przez użytkownika, a nawet może się wydawać, że całkowicie zamrozi system. Ten stan jest powszechnie znany jako blokada na żywo . W takim stanie system zużywa większość swoich zasobów na przerwania przetwarzania zamiast na wykonywanie innej pracy. Dla użytkownika końcowego wydaje się, że w ogóle nic nie przetwarza, ponieważ często nie ma danych wyjściowych. Burza przerwań jest czasami mylona z rzucaniem , ponieważ oba mają podobne objawy (brak reakcji lub powolna reakcja na dane wprowadzane przez użytkownika, niewielkie wyniki lub ich brak).

Typowe przyczyny to: źle skonfigurowany lub wadliwy sprzęt, wadliwe sterowniki urządzeń, wady systemu operacyjnego lub metastabilność jednego lub kilku komponentów. Ten ostatni warunek rzadko występuje poza sprzętem prototypowym lub amatorskim.

Większość nowoczesnych systemów sprzętowych i operacyjnych ma metody łagodzenia skutków burzy przerwań. Na przykład większość Ethernet implementuje „ograniczenie szybkości” przerwań, co powoduje, że kontroler czeka programowalną ilość czasu między każdym wygenerowanym przerwaniem. Gdy nie ma ich w urządzeniu, podobne funkcje są zwykle zapisane w sterowniku urządzenia i/lub w samym systemie operacyjnym.

Najczęstszą przyczyną jest sytuacja, gdy urządzenie „za” innym sygnalizuje przerwanie APIC (Zaawansowany programowalny kontroler przerwań). Większość komputerowych urządzeń peryferyjnych generuje przerwania przez APIC, ponieważ liczba przerwań jest zawsze mniejsza (zwykle 15 dla nowoczesnych komputerów PC) niż liczba urządzeń. System operacyjny musi następnie wysłać zapytanie do każdego sterownika zarejestrowanego w tym przerwaniu, aby zapytać, czy przerwanie pochodzi z jego sprzętu. Wadliwe sterowniki mogą zawsze twierdzić „tak”, powodując, że system operacyjny nie wysyła zapytań do innych sterowników zarejestrowanych w tym przerwaniu (jednocześnie można przetwarzać tylko jedno przerwanie). Urządzenie, które pierwotnie zażądało przerwania, nie otrzymuje zatem obsługi przerwania, więc generowane jest nowe przerwanie (lub nie jest kasowane), a procesor zostaje zalany ciągłymi sygnałami przerwań. Każdy system operacyjny może blokować się podczas burzy przerwań spowodowanej taką usterką. A debugger jądra może zwykle przerwać burzę, usuwając wadliwy sterownik, pozwalając sterownikowi „pod” uszkodzonym na usunięcie przerwania, jeśli dane wejściowe użytkownika są nadal możliwe.

Ponieważ sterowniki są najczęściej wdrażane przez firmy zewnętrzne, większość systemów operacyjnych ma również tryb odpytywania , w którym wysyłane są zapytania o oczekujące przerwania w ustalonych odstępach czasu lub w trybie okrężnym. Ten tryb można ustawić globalnie, na podstawie każdego sterownika, każdego przerwania lub dynamicznie, jeśli system operacyjny wykryje stan błędu lub nadmierne generowanie przerwań. Tryb odpytywania może być włączany dynamicznie, gdy liczba przerwań lub wykorzystanie zasobów spowodowane przez przerwanie przekroczy określone progi. Kiedy te progi nie są już przekraczane, system operacyjny może zmienić przerywający sterownik, przerwanie lub obsługę przerwań globalnie, z trybu przerwania na tryb odpytywania. Ograniczanie częstotliwości przerwań w sprzęcie zwykle wyklucza użycie trybu odpytywania, ale nadal może się zdarzyć podczas normalnej pracy podczas intensywnych operacji we/wy, jeśli procesor nie jest w stanie przełączać kontekstów wystarczająco szybko, aby nadążyć.

Historia

Być może pierwsza burza przerwana miała miejsce podczas zejścia Apollo 11 na Księżyc w 1969 roku.

Rozważania

Aby uzyskać optymalne wyniki, należy dokładnie skonfigurować ograniczenie szybkości przerwań. Na przykład Ethernet z funkcją ograniczania częstotliwości przerwań buforuje pakiety otrzymane z sieci pomiędzy każdym przerwaniem. Jeśli szybkość zostanie ustawiona na zbyt niską, bufor kontrolera zostanie przepełniony, a pakiety będą odrzucane. Szybkość musi uwzględniać szybkość, z jaką bufor może się zapełniać między przerwaniami, oraz opóźnienie przerwania między przerwaniem a przesłaniem bufora do systemu.

Łagodzenie przerwań

Istnieją podejścia do problemu oparte na sprzęcie i oprogramowaniu. Na przykład FreeBSD wykrywa burze przerwań iw odpowiedzi na pewien czas maskuje problematyczne przerwania. ^{[ potrzebne źródło ]}

System używany przez NAPI jest przykładem podejścia sprzętowego: system (sterownik) uruchamia się w stanie włączonym przerwaniem, a następnie moduł obsługi przerwań wyłącza przerwanie i pozwala wątkowi/zadaniu obsłużyć zdarzenie (zdarzenia), a następnie sonduje zadanie urządzenia, przetwarzając pewną liczbę zdarzeń i umożliwiając przerwanie.

Innym ciekawym podejściem wykorzystującym wsparcie sprzętowe jest takie, w którym urządzenie generuje przerwanie, gdy stan kolejki zdarzeń zmienia się z „pustej” na „niepustą”. Następnie, jeśli nie ma wolnych deskryptorów DMA w ogonie RX FIFO, urządzenie odrzuca zdarzenie. Zdarzenie jest następnie dodawane do ogona, a wpis FIFO jest oznaczany jako zajęty. Jeśli w tym punkcie wpis (tail-1) jest wolny (wyczyszczony), zostanie wygenerowane przerwanie (przerwanie poziomu) i wskaźnik ogona zostanie zwiększony. Jeśli sprzęt wymaga potwierdzenia przerwania, zrobi to CPU (obsługa przerwań), obsłuży prawidłowe deskryptory DMA na początku i powróci z przerwania.

Zobacz też