Avbryta stormen - Interrupt storm

I operativsystem är en avbrottsstorm en händelse under vilken en processor får ett överdrivet antal avbrott som förbrukar majoriteten av processorns tid. Stormstormar orsakas vanligtvis av hårdvaruenheter som inte stöder avbrottsbegränsning.

Bakgrund

Eftersom avbrotts bearbetning är typiskt ett icke- förköpsrätt uppgift i tidsdelning operativsystem , kommer en avbrotts storm orsaka trög respons på användarinmatning, eller till och med verkar frysa systemet helt. Detta tillstånd är allmänt känt som live-lås . I ett sådant tillstånd spenderar systemet större delen av sina resurser på avbrott i stället för att slutföra annat arbete. För slutanvändaren verkar det inte behandla någonting alls eftersom det ofta inte finns någon utdata. En avbrottsstorm misstas ibland för att krossa , eftersom de båda har liknande symtom (svarar inte eller trögt svar på användarinmatning, liten eller ingen effekt).

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

De flesta moderna hårdvaru- och operativsystem har metoder för att mildra effekten av en avbrotstorm. 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 det inte finns i enheten skrivs vanligtvis liknande funktioner 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 datorutrustningar genererar avbrott via en APIC eftersom antalet avbrott oftast är mindre (vanligtvis 15 för den moderna PC) än antalet enheter. Operativsystemet måste sedan fråga varje drivrutin som är registrerad för det avbrottet för att fråga om avbrottet härstammar från dess hårdvara. Felaktiga drivrutiner kan alltid göra anspråk på "ja", vilket gör att operativsystemet inte frågar andra drivrutiner som är registrerade för det avbrottet (endast ett avbrott kan behandlas åt gången). Enheten som ursprungligen begärde avbrottet får därför inte sitt avbrott, så ett nytt avbrott genereras (eller rensas inte) och processorn blir överbelastad med kontinuerliga avbrottssignaler. Alla operativsystem kan spärras under en storm som orsakas av ett sådant fel. En kernel debugger kan oftast bryta storm genom lossning av felaktig drivrutin, vilket gör att föraren "under" den felaktiga en att rensa avbrottet, om användarens input är fortfarande möjligt.

Eftersom drivrutiner oftast implementeras av en tredje part, har de flesta operativsystem också ett avfrågningsläge som frågar efter väntande avbrott med fasta intervall eller på ett rund-robin-sätt. Detta läge kan ställas in globalt, per förare, per avbrott eller dynamiskt om operativsystemet upptäcker ett felförhållande eller överdriven avbrottsgenerering. Ett avfrågningsläge kan aktiveras dynamiskt när antalet avbrott eller resursanvändningen orsakad av ett avbrott passerar vissa trösklar. När dessa trösklar inte längre överskrids kan ett operativsystem sedan ändra avbrottsdrivrutinen, avbryta eller avbryta hanteringen globalt, från ett avbrottsläge till ett avfrågningsläge. Avbrytningshastighetsbegränsning i hårdvara upphäver 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 takten.

Historia

Kanske den första avbrotstormen inträffade under Apollo 11s månstig 1969.

Överväganden

Avbrytningshastighetsbegränsning måste konfigureras noggrant för bästa resultat. Till exempel kommer en Ethernet- styrenhet med avbrottshastighetsbegränsning att buffra paketen som den tar emot från nätverket mellan varje avbrott. Om hastigheten är inställd för låg, kommer controllerns buffert att rinna över och paket kommer att tappas. Hastigheten måste ta hänsyn till hur snabbt bufferten kan fylla mellan avbrott och avbrottsfördröjningen mellan avbrottet och överföringen av bufferten till systemet.

Avbryt mildrande

Det finns hårdvarubaserade och programvarubaserade metoder för problemet. Till exempel, FreeBSD upptäcker avbrotts stormar och masker problematiska avbrott under en tid som svar.

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

Ett annat intressant tillvägagångssätt med hjälp av hårdvarustöd är en där enheten genererar avbrott när tillståndet för händelsekön ändras från "tom" till "inte tom". Sedan, om det inte finns några gratis DMA-deskriptorer vid RX FIFO-svansen, tappar enheten händelsen. Händelsen läggs sedan till i svansen och FIFO-posten markeras som upptagen. Om ingången (svans − 1) vid den punkten är fri (rensad) genereras ett avbrott (nivåavbrott) och svanspekaren ökas. Om hårdvaran kräver att avbrottet bekräftas kommer CPU (avbrottshanteraren) att göra det, hantera de giltiga DMA-deskriptorerna vid huvudet och återvända från avbrottet.

Se även

Referenser