Liten Linux-förändring ger stor effekt

En interrupt är ju en signal till operativsystemet att en hårdavaruenhet behöver göra ett jobb "just nu". IRQ-kod ska inte ta lång tid att exekvera, bara det nödvändigaste, och sen släppa tillbaka kontrollen till OS:et. Excempel på IRQ är t.ex nätverkspaket som nämnts, men också allt annat som BT, ljud, grafik, I/O-enheter (mus/tangentbord), lagring m.m. IRQ-kod finns väl framförallt i drivrutiner.
Att de bygger om hanteringen här med att IRQ "kan vänta lite" verkar ju konceptuellt märkligt, men jag antar att de vet vad de gör med den här förändringen. Uppenbarligen så är fördröjningarna inom marginalerna.

EDIT: Efter att ha läst på lite bättre ser jag att ändringen endast verkar ha med just nätverkshårdvara att göra, inte övriga IRQ.

Lite goda nyheter i ett annars dystert nyhetsflöde!

"enkelt uttryckt ber processorn att vänta ett ögonblick så att den hinner slutföra en viktig uppgift."

Nja, en interrupt i det här fallet används som ett sätt för nätverkskortet att få operativsystemet att hantera inkommande data exempelvis, det är ett sätt för I/O-enheter att meddela OS att de behöver ta hand om saker på hårdvarans "förmaning". Läsa data ur hårdvarans buffert.

Ett annat exempel är gamla PS/2-kontakter för tangentbord. Tangentbordet triggar en interrupt varje gång en tangent trycks ned och i den interrupt-proceduren läser OS av vilket tangent som tycktes ned.

Misstänker att om man har kod som ursprungligen designades för en 386a på 20MHz så kan man vänta några fler cykler innan man exekverar en IRQ om processorn är ett par hundra gånger snabbare.

Mer läsvärt om du faktiskt undrar vad det är de gjort:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linu...

Tack. Jag läste väl inte allt i detalj, men ändringen verkar vara centrerad just runt nätverkshårdvara och inte övriga delsystem såvitt jag kan se. Men man kan väl anta av detta att just nätverksstacken drar en hel del IRQ-anrop och optimering här ger ett bra utfall.

OT. Hur går det med rapporteringen kring DeepSeek? SweLångsammers!

Om jag förstått det rätt så handlar det om att växla mellan IRQ och busy-polling beroende på nätverksbelastning. IRQ är effektivt när belastningen är låg eftersom CPUn då kan vila och låta nätverkskortet säga till när det finns paket att hantera, men vid hög belastning så orsakar det onödig overhead när IRQ avbryter programmet hela tiden.

Busy-polling innebär istället att CPUn frågar nätverkskortet om det finns paket att hantera i en loop, vilket är oeffektivt vid låg belastning eftersom CPUn då ligger på 100% belastning hela tiden även om det inte finns något att göra men effektivt vid hög belastning eftersom CPUn kan fråga efter fler paket när den är redo istället för att bli avbruten av IRQ hela tiden.

Om det sänker elräkningen så ger det väl liten effekt?

Jag anar ugglor i mossen, känns lite som att hävda om kundtjänsten slutar svara på frågor, så ger några kunder upp och löser det själva, så kan kundtjänsten bli mer effektiv.

Det här kan nog leda till system som inte svara lika snabbt och att paket med farlig data får det lättare att sprida sig obemärkt, men vad vet jag egentligen, kanske är det här en toppenlösning.
Jag skulle dock inte välja att fokusera på elbesparing utan istället mer effektiv kod, adblocker är ju också elbesparing med samma logik.

Varken kernelutvecklare eller professorer i datateknik brukar i allmänhet vara klåpare när det kommer till de här sakerna men de är ofta öppna för tips om du hör av dig till dem och förklarar vad de har missat!

Här finns kontaktuppgifter till Martin Karsten som nämns i artikeln, forskare i mjukvara, nätverk och prestandaoptimering: https://cs.uwaterloo.ca/~mkarsten/

Det är inte meningen att det ska fungera i 99% av fallen, det är en optimering för ett specifikt användningsfall och kräver att applikationer uttryckligen använder funktionaliteten. Det har även tagit många revisioner med mycket community-feedback innan koden till slut accepterades, så den är nog rätt mogen vid det här laget.

Det är inte paket på posten vi pratar om direkt..

inte alls vad som händer här. Det som händer här när IRQ tar mer energi än ren polling är när så pass mycket data kommer in att övriga delar av systemet redan är upptaget med att hantera den data som precis kom och nu kommer det en IRQ som avbryter det och säger "nu kom det lite till". Mycket effektivare då att helt ta bort IRQ:n och helt sonika hantera klart den data som du har och sedan bara kolla med NIC:en om det finns mer data, om det inte finns mer data så kan man slå på IRQ igen men om det finns data så är det bara att processa på och kolla igen nästa gång.

Dvs det handlar om tillfällen när IRQ avbryter hantering av sådant som precis triggats av IRQ. Vid low-latency uppsättningar så har man oftast tidigare konfiguerat kärnan så att den alltid gör busy-polling (dvs stänger alltid av IRQ) vilket ger betydligt lägre latens, dock extremt mycket högre enerianvändning om det inte skickas så pass mycket data vid tillfället.

Vi pratar om servrar här, en enda EPYC 9686X har en TDP på 400W och du har ofta 2 i samma server. Kylningen finns ju där primärt för att få fort den värme som genereras av CPU:n. Ju mer / oftare som du kan få CPU:n att klocka ner desto mindre energi drar CPU:n och desto mindre värme måste du kyla.

Switchar och routrar genererar inte speciellt mycket värme (i relation till en server CPU).

Linux har sedan väldigt långt tillbaka (NAPI från 2002) växlat mellan att driva nätverkskort med en kombination av IRQ och busy-polling.

Att till 100 % låta applikationer styra polling är bra så långe som applikationer uppför sig, men blir katastrofalt om den inte gör det. Så går inte att köra en sådan modell med mindre än att då helt räkna applikationen som en del av OS-kärnan.

Nyheten här är egentligen otroligt simpel: en till timer.

Processen i NAPI är att NIC ger ett RX IRQ när ett paket kommer in. "Top-half" av IRQ-rutinen maskar då den IRQ-kanalen och schemalägger ett "soft-IRQ" som hanterar paketet. I detta läge kommer alltså inga fler IRQs.

ALLA paket (eller normalt alla paket, finns en övre "budget" när man låter andra saker komma emellan men normalfallet är alla) processas sedan i soft-IRQ. När man är klar slås IRQ på igen.

Här är nyheten. Vid hög last kommer ett nytt IRQ nästan direkt triggas igen, det kommer i praktiken hända innan applikationer haft en chans att beta av allt som redan kommit in -> detta leder till lägre IPC då cacha:ar trashas av frekventa kontext-switchar.

Istället för att direkt slå på IRQ när man processat alla paket startar man nu en timer. Om applikationen är "well-behaved" kan man nu helt driva all nätverkstrafik mot den RX-ringen med IRQ permanent avslaget så länge det kommer paket "tillräckligt snabbt".

Om applikationen får för sig att sluta poll:a av någon anledning triggar timer som slår på IRQ så inte andra applikationer blir lidande. "Worst case tail-latency" begränsas då av denna timer.

Så länge applikationen uppför sig så kommer paket drivas av att den rätt snabbt går in för att kolla efter paket.

Besparingen kommer av att det är mer effektivt att driva trafik med IRQ avslaget vid hög last. Alt. om man kör out-of-kernel polling (t.ex. via DPDK) så är vinsten att detta ger nästan samma prestanda, fast utan extremt hög effekt när det kommer få paket.