Avbryt stormen

I operativsystem är en avbrottsstorm en händelse under vilken en processor tar emot ett orimligt antal avbrott som förbrukar större delen av processorns tid. Avbrottsstormar orsakas vanligtvis av hårdvaruenheter som inte stöder begränsning av avbrottshastighet.

Bakgrund

Eftersom avbrottsbearbetning typiskt sett är en oåterkallelig uppgift i operativsystem med tidsdelning , kommer en avbrottsstorm att orsaka trög respons på användarinmatning, eller till och med tyckas frysa systemet helt. Detta tillstånd är allmänt känt som live lock . I ett sådant tillstånd spenderar systemet det mesta av sina resurser på att bearbeta avbrott istället för att slutföra annat arbete. För slutanvändaren verkar det inte bearbeta någonting alls eftersom det ofta inte finns någon utdata. En avbrottsstorm förväxlas ibland med att slå , eftersom de båda har liknande symtom (svarar inte eller svarar långsamt på användarinmatning, liten eller ingen utmatning).

Vanliga orsaker inkluderar: felkonfigurerad eller felaktig hårdvara, felaktiga drivrutiner, brister i operativsystemet eller metastabilitet i en eller flera komponenter. Det senare tillståndet uppstår sällan utanför prototyp eller amatörbyggd hårdvara.

De flesta moderna hårdvara och operativsystem har metoder för att mildra effekten av en avbrottsstorm. Till exempel implementerar de flesta Ethernet- styrenheter avbrotts-"hastighetsbegränsning", vilket gör att styrenheten väntar en programmerbar tid mellan varje avbrott den genererar. När den inte finns i enheten skrivs liknande funktionalitet vanligtvis in i enhetsdrivrutinen och/eller själva operativsystemet.

Den vanligaste orsaken är när en enhet "bakom" en annan signalerar ett avbrott till en APIC (Advanced Programmable Interrupt Controller). De flesta datortillbehör genererar avbrott via en APIC eftersom antalet avbrott oftast är mindre (vanligtvis 15 för den moderna datorn) än antalet enheter. OS måste sedan fråga varje drivrutin som är registrerad för det avbrottet för att fråga om avbrottet härrörde från dess hårdvara. Felaktiga drivrutiner kan alltid hävda "ja", vilket gör att operativsystemet inte frågar andra drivrutiner som är registrerade för det avbrottet (endast ett avbrott kan bearbetas åt gången). Enheten som ursprungligen begärde avbrottet får därför inte sitt avbrott betjänat, så ett nytt avbrott genereras (eller rensas inte) och processorn översvämmas av kontinuerliga avbrottssignaler. Vilket operativsystem som helst kan låsa sig under en avbrottsstorm orsakad av ett sådant fel. En kärnfelsökare kan vanligtvis bryta stormen genom att ladda ur den felaktiga drivrutinen, så att drivrutinen "under" den felaktiga kan rensa avbrottet, om användarinmatning fortfarande är möjlig .

Eftersom drivrutiner oftast implementeras av en tredje part, har de flesta operativsystem också ett pollingläge som frågar efter väntande avbrott med fasta intervaller eller på ett round-robin-sätt. Detta läge kan ställas in globalt, per drivrutin, per avbrott eller dynamiskt om operativsystemet upptäcker ett feltillstånd eller överdriven avbrottsgenerering. Ett avfrågningsläge kan aktiveras dynamiskt när antalet avbrott eller resursanvändningen som orsakas av ett avbrott passerar vissa trösklar. När dessa tröskelvärden inte längre överskrids, kan ett operativsystem sedan ändra den avbrytande drivrutinen, avbryta eller avbryta hanteringen globalt, från ett avbrottsläge till ett avfrågningsläge. Begränsning av avbrottshastighet i hårdvara förnekar vanligtvis användningen av ett avfrågningsläge, men kan fortfarande inträffa under normal drift under intensiv I/O om processorn inte kan byta sammanhang tillräckligt snabbt för att hålla jämna steg.

Historia

Kanske inträffade den första avbrottsstormen under Apollo 11:s månnedstigning 1969.

Överväganden

Avbrottshastighetsbegränsning måste konfigureras noggrant för optimala resultat. Till exempel kommer en Ethernet- kontroller med avbrottshastighetsbegränsning att buffra paketen den tar emot från nätverket mellan varje avbrott. Om hastigheten ställs in för lågt kommer styrenhetens buffert att svämma över och paket kommer att släppas. Hastigheten måste ta hänsyn till hur snabbt bufferten kan fyllas mellan avbrotten, och avbrottslatensen mellan avbrottet och överföringen av bufferten till systemet.

Avbrottsförmildrande

Det finns hårdvarubaserade och mjukvarubaserade metoder för problemet. Till exempel FreeBSD avbrottsstormar och maskerar problematiska avbrott under en tid som svar. ^{[ citat behövs ]}

Systemet som används av NAPI är ett exempel på det hårdvarubaserade tillvägagångssättet: systemet (drivrutinen) startar i avbrottsaktiverat tillstånd, och avbrottshanteraren inaktiverar sedan avbrottet och låter en tråd/uppgift hantera händelsen/händelserna och sedan uppgiftsundersökningar enheten, bearbetar ett antal händelser och aktiverar avbrottet.

Ett annat intressant tillvägagångssätt som använder hårdvarustöd är ett där enheten genererar avbrott när händelseköns tillstånd ändras från "tom" till "inte tom". Sedan, om det inte finns några lediga DMA-deskriptorer vid RX FIFO-svansen, släpper enheten händelsen. Händelsen läggs sedan till i svansen och FIFO-posten markeras som upptagen. Om ingången (tail−1) vid den punkten är ledig (rensas), kommer ett avbrott att genereras (nivåavbrott) och svanspekaren kommer att ökas. Om hårdvaran kräver att avbrottet bekräftas, kommer CPU:n (avbrottshanteraren) att göra det, hantera de giltiga DMA-deskriptorerna i spetsen och återvända från avbrottet.

Se även