Vam tancar la lliçó anterior amb tres caixes sense obrir i un problema plantejat amb números. Les caixes: què fa exactament la CPU quan arriba una interrupció, com un controlador es registra davant del nucli i quin contracte compleix, i com funciona el DMA per dins. El problema: a 500.000 lectures per segon, un nucli sencer es dedicaria només a atendre interrupcions, i això no pot ser la solució final.

Aquesta lliçó obre les tres caixes i resol el problema. Veuràs el recorregut complet d'una interrupció des de la línia IRQ fins al gestor, entendràs per què el codi d'un gestor no pot dormir ni bloquejar-se, i per què aquesta restricció obliga a partir la feina en dues meitats. Aprendràs a llegir /proc/interrupts línia a línia, que és una de les sortides més informatives del sistema. I seguiràs el camí complet d'un paquet amb lectures d'estació, aquesta vegada sense deixar cap capa sense explicar.

És l'última lliçó del mòdul 2, així que al final recapitularem les set i enllaçarem amb el mòdul 3.

1. Què és un controlador de dispositiu
2. El contracte amb el nucli: la interfície d'operacions de fitxer
3. Registre del driver i mòduls carregables
4. Espai de nucli davant d'espai d'usuari per als drivers
5. Interrupcions: línia IRQ, vector i taula de vectors
6. La controladora d'interrupcions: del PIC a l'APIC
7. Què fa la CPU en rebre una interrupció
8. El context d'interrupció i les seves regles
9. Emmascarament i interrupcions compartides
10. Meitat superior i meitat inferior
11. /proc/interrupts interpretat línia a línia
12. MSI i MSI-X
13. DMA en detall: descriptors, coherència i IOMMU
14. El camí complet d'un paquet amb lectures
15. Latència d'interrupció i el seu impacte
16. Tancament del mòdul 2

Un controlador de dispositiu (device driver) és el codi que tradueix les operacions genèriques del nucli en les operacions concretes d'un model de maquinari.

Convé distingir dues coses que en català tenen noms gairebé idèntics i es confonen constantment:

En aquesta lliçó, quan diguem driver ens referim al programari; quan diguem controladora del dispositiu o xip, al maquinari.

El driver és l'única peça del sistema que coneix els detalls bruts: quin registre cal escriure per iniciar una transferència, en quin bit hi ha el senyal de «llest», quants microsegons cal esperar després d'un reinici, quina errata de silici té la revisió B2 del xip.

I la seva magnitud dins del nucli de Linux és reveladora:

Els drivers són el 63 % del codi del nucli. I a l'arbre de fonts de Linux la proporció és similar: més de la meitat dels milions de línies són controladors de dispositiu. El nucli pròpiament dit —planificador, memòria, sistemes de fitxers, xarxa— és la part petita.

Un driver no pot fer el que vulgui: ha de complir un contracte amb el nucli. Aquest contracte és una estructura de punters a funció. Per a un dispositiu de caràcter:

Com funciona el mecanisme, que és el mateix despatx per taula que vam veure a 01-06 amb les crides al sistema:

• Quan un procés crida read() sobre /dev/meteora/estacio-nord, el nucli recorre el camí que ja coneixes: syscall → taula de crides → sys_read → capa VFS.
• La capa VFS consulta el número major del fitxer, troba el driver registrat i crida el punter .read del seu file_operations.
• Aquest punter apunta a meteora_read, codi específic d'aquest dispositiu.

És polimorfisme implementat amb punters a funció en C: la mateixa crida read() acaba executant codi diferent segons el dispositiu, sense que el codi que crida en sàpiga res.

Els mètodes habituals del contracte:

ioctl mereix un comentari. És la via d'escapament del model «tot és un fitxer»: permet operacions que no són llegir ni escriure. Expulsar un CD, configurar la velocitat d'un port sèrie, consultar estadístiques d'una targeta. Que existeixi demostra els límits de l'abstracció de fitxer, exactament com els sockets en demostraven els límits per un altre costat. ioctl és el reconeixement pragmàtic que no tot cap a read/write.

Un esquelet de driver simplificat:

Punts que cal entendre d'aquest codi:

• copy_to_user() en lloc de memcpy(). És obligatori i no és una formalitat. El punter buf ve de l'espai d'usuari i no és de fiar: podria apuntar a memòria del nucli, a una adreça no mapejada o a memòria d'un altre procés. copy_to_user valida el rang, gestiona la fallada de pàgina si la pàgina no hi és, i retorna el nombre de bytes que no ha pogut copiar. Un memcpy directe seria una vulnerabilitat d'escalada de privilegis de manual. La marca __user al prototip permet, a més, que eines d'anàlisi estàtica detectin l'error.
• Retornar -EIO i -EFAULT, en negatiu. Aquest és exactament el conveni que vam rastrejar a 01-06: el nucli retorna l'error com un valor negatiu petit, i la biblioteca C el converteix en -1 més errno.
• register_chrdev amb major 0 demana al nucli que assigni un número lliure. Fixar un major a mà només funciona per als números reservats oficialment.
• module_init i module_exit defineixen els punts d'entrada i de sortida del mòdul, que és el que fa possible carregar-lo i descarregar-lo en calent.

Reprenem aquí allò de 01-05: els mòduls carregables permeten afegir codi al nucli en execució.

La línia alias és la clau de la càrrega automàtica: diu que aquest mòdul gestiona el dispositiu PCI amb fabricant 8086 (Intel) i dispositiu 1521 (I350). Quan el bus PCI enumera una targeta amb aquests identificadors, udev busca un mòdul amb l'àlies corresponent i el carrega sense intervenció humana.

Aquí hi ha la cadena completa: l'identificador del maquinari condueix al nom del mòdul.

Avantatges dels mòduls, reprenent la discussió d'arquitectura del nucli de 01-05:

I una limitació important: un mòdul s'executa amb tots els privilegis del nucli. No hi ha aïllament. Un mòdul amb una errada pot corrompre qualsevol estructura del sistema.

Aquí reprenem i tanquem el debat d'arquitectures de 01-05, ara amb dades concretes.

Per què un driver defectuós és perillós. Un driver corre a l'anell 0, així que:

• Pot escriure a qualsevol adreça de memòria física, incloses les estructures del nucli i la memòria de qualsevol procés.
• Pot executar instruccions privilegiades: deshabilitar interrupcions, canviar la taula de pàgines, reprogramar la MMU.
• No hi ha MMU que el protegeixi d'ell mateix: els mecanismes de protecció que vam estudiar a 02-03 i 02-04 protegeixen els processos entre si, però el nucli és per damunt d'ells.

Un punter nul en un driver:

Com es llegeix aquesta traça:

• supervisor read access in kernel mode: la fallada s'ha produït a l'anell 0. Si hagués estat en usuari, seria un simple SIGSEGV.
• RIP: meteora_interrupt_handler+0x2a [meteora_drv]: l'adreça exacta on ha fallat, amb el mòdul culpable identificat entre claudàtors.
• Tainted: G O: el nucli està «contaminat» per un mòdul extern. Els desenvolupadors del nucli fan servir aquesta marca per saber que el problema pot no ser seu.
• Fatal exception in interrupt: i aquí hi ha el més greu. La fallada s'ha produït dins d'un gestor d'interrupció, on el nucli no pot simplement matar el procés responsable (no hi ha procés: Comm: swapper/2 és el fil ociós). No hi ha recuperació possible: kernel panic.

Compara-ho amb el mateix error a meteo-api: mor un procés, systemd el reinicia, es perden unes peticions. Aquí mor la màquina sencera.

Drivers a l'espai d'usuari. L'alternativa existeix i es fa servir en casos concrets:

El cas de DPDK és paradoxal i molt instructiu: mou el driver a l'espai d'usuari no per seguretat, sinó per rendiment. Mapeja els registres de la targeta directament dins del procés i fa sondeig continu, eliminant interrupcions i crides al sistema. Aconsegueix processar milions de paquets per segon a canvi de dedicar nuclis sencers a girar en un bucle. És exactament l'espera activa de la lliçó anterior, triada deliberadament perquè a aquestes taxes surt més barata que interrompre.

Una interrupció és un senyal del maquinari que fa que la CPU suspengui el que està fent i executi un codi predeterminat.

El vocabulari, que cal tenir clar:

A x86-64 hi ha 256 vectors, repartits així:

Alguns vectors d'excepció que ja coneixes de lliçons anteriors:

I aquí convé fixar una classificació que es confon sovint:

La diferència clau és la sincronia. Una excepció es produeix sempre al mateix punt si repeteixes el programa amb les mateixes dades: és conseqüència de la instrucció que s'estava executant. Una interrupció arriba quan al món exterior li ve de gust i pot caure entre dues instruccions qualssevol. Aquesta asincronia és la font de tota la dificultat del codi d'interrupcions.

La IDT viu a la memòria i la seva adreça és al registre IDTR, carregat amb la instrucció privilegiada lidt que vam veure a la taula de 01-06. Cada entrada conté l'adreça del gestor, el segment i els permisos.

La CPU té molt poques potes d'interrupció, així que cal un xip intermediari que multiplexi les línies de tots els dispositius.

PIC 8259A (1976): dos xips encadenats, 15 línies IRQ útils.

Aquella assignació de 1981 encara es reconeix avui a /proc/interrupts.

APIC (Advanced Programmable Interrupt Controller) el va substituir, i les seves millores són les que fan viable un servidor multiprocessador:

L'APIC té dues parts:

• Local APIC: un per nucli, integrat a la CPU. Rep les interrupcions dirigides a aquell nucli i gestiona el temporitzador local i les interrupcions entre processadors.
• I/O APIC: al xipset. Rep les línies dels dispositius i les encamina al Local APIC del nucli que correspongui.

Que l'APIC pugui dirigir una interrupció a un nucli concret és el que permet el smp_affinity que veurem en parlar de /proc/interrupts, i el que fa possible que una targeta amb diverses cues reparteixi la seva feina entre nuclis.

Aquest és el recorregut exacte, i convé comparar-lo mentalment amb el de la crida al sistema de 01-06:

Els detalls que importen:

1. La instrucció en curs s'acaba. La CPU no interromp a mitja instrucció (amb comptades excepcions per a instruccions molt llargues, que són represes). Això garanteix un estat consistent.
2. Es desa l'estat mínim automàticament: punter d'instrucció, punter de pila, registre de banderes i selector de segment. Ho fa el maquinari, no el programari.
3. Es canvia a la pila de nucli, exactament com en un syscall. El gestor no fa servir mai la pila del procés interromput.
4. Les interrupcions es deshabiliten si l'entrada de la IDT és una interrupt gate (l'habitual). Això evita que una altra interrupció s'imbriqui immediatament.
5. L'EOI és obligatori. Si el gestor no envia el senyal de fi d'interrupció a l'APIC, aquell dispositiu no tornarà a interrompre mai més. És un dels errors clàssics en escriure drivers, i el seu símptoma és que el dispositiu funciona exactament una vegada i després es queda mut.

Comparació amb el que ja saps:

La fila crucial és la penúltima: una crida al sistema s'executa en nom d'un procés concret, mentre que una interrupció s'executa en el context de qui toqués estar executant-se, que pot ser qualsevol. D'aquí surten totes les restriccions de l'apartat següent.

Un gestor d'interrupció s'executa en context d'interrupció, també anomenat context atòmic. És un entorn amb regles molt estrictes:

Comprendre el perquè de la primera regla és la clau de tota la resta. Quan l'ingestor crida read() i no hi ha dades, el nucli el posa en estat S i planifica un altre procés: hi ha un task_struct on aparcar-lo. Però un gestor d'interrupció no pertany a cap procés. Si s'adormís, a qui es posaria en estat S? Al procés que casualment s'estava executant, que no hi té res a veure? I qui el despertaria?

Recorda la traça del kernel panic: Comm: swapper/2. El gestor es va executar «sobre» el fil ociós, que era el que hi havia en aquell nucli. No era la seva interrupció ni la seva feina.

Les quatre decisions del gestor correcte:

1. Comprovar si la interrupció és seva abans de res, perquè la línia pot estar compartida. Retornar IRQ_NONE permet que el nucli provi amb el driver registrat següent.
2. Reconèixer-la al maquinari escrivint al registre d'estat. Sense això, el dispositiu continuaria afirmant la línia i es generaria una tempesta d'interrupcions infinita.
3. spin_lock_irqsave en lloc de mutex_lock. Un mutex dorm si està ocupat; un spinlock gira esperant, que és l'únic que es pot fer en context atòmic. La variant irqsave desa a més l'estat de les interrupcions i les deshabilita, i evita l'interbloqueig amb un mateix si la mateixa interrupció es repetís.
4. Delegar tota la feina real a la meitat inferior. Només s'ha incrementat un comptador i s'ha programat feina diferida.

Emmascarament és deshabilitar temporalment una interrupció, i hi ha tres nivells:

cli és la instrucció privilegiada que vam provar a 01-06 i que provocava un SIGSEGV en mode usuari. Ara entens per què ha de ser privilegiada amb tanta rotunditat: un procés que pogués deshabilitar les interrupcions impediria que el temporitzador les hi tragués, monopolitzant la CPU per sempre i trencant completament la planificació expropiativa de 02-02.

Les NMI (Non-Maskable Interrupt) no es poden emmascarar de cap manera. Es reserven per a fallades catastròfiques: error de paritat de memòria, el temporitzador de vigilància, senyals de fallada de maquinari. Si el sistema deixa de respondre del tot, la NMI del watchdog és la que força un bolcat de diagnòstic.

Interrupcions compartides. Amb poques línies IRQ i molts dispositius, uns quants poden compartir línia:

La IRQ 16 la comparteixen la controladora USB i el bus SMBus. Quan s'activa, el nucli no sap quin dels dos ha estat, així que crida els gestors de tots els drivers registrats en aquella línia, en ordre, fins que un retorna IRQ_HANDLED.

D'aquí la importància de la comprovació de l'apartat anterior: un driver que retornés IRQ_HANDLED sense comprovar si la interrupció era seva robaria les interrupcions de l'altre dispositiu, que deixaria de funcionar amb un símptoma impossible de diagnosticar.

L'últim argument és essencial en línies compartides: és el que permet que el gestor sàpiga a quina instància de dispositiu correspon la crida.

Aquí hi ha la idea central del disseny d'interrupcions a Linux, i resol una tensió real.

La tensió: un gestor d'interrupció ha de ser rapidíssim, perquè s'executa amb interrupcions deshabilitades i bloqueja tota la resta. Però la feina que genera una interrupció pot ser considerable: processar un paquet de xarxa implica recórrer la pila IP, buscar el socket, actualitzar estadístiques, despertar processos.

La solució: partir-la en dues.

Els tres mecanismes de meitat inferior a Linux:

• softirq: la més ràpida i l'única que escala. N'hi ha un nombre fix definit en temps de compilació, així que només la fan servir els subsistemes principals del nucli. La mateixa softirq es pot executar simultàniament en diverses CPU, cosa que exigeix que el seu codi sigui reentrant.
• tasklet: construïda sobre softirq, més fàcil de fer servir. Una tasklet concreta no s'executa mai en dues CPU alhora, cosa que simplifica la sincronització a costa d'escalabilitat.
• workqueue: s'executa en un fil del nucli, és a dir, en context de procés. És l'única que pot dormir, així que és l'opció quan cal reservar memòria amb GFP_KERNEL, esperar un mutex o fer E/S.

Lectura d'aquesta sortida:

• NET_RX és 30 vegades més gran a CPU0 (1.284.102 davant de ~40.000). Tot el trànsit de xarxa entrant es processa en un sol nucli. Amb una targeta d'una sola cua és l'esperable; amb una de multicua, indica que l'afinitat d'interrupcions no està ben repartida.
• TIMER està repartit uniformement, com ha de ser: cada nucli té el seu temporitzador local de l'APIC.
• BLOCK són les interrupcions de dispositius de bloc completades, correlacionades amb l'activitat del RAID que vam veure a 02-05.

El repartiment és clar: la meitat superior triga menys d'1 µs i només programa feina. La meitat inferior processa fins a 64 paquets recorrent tota la pila de xarxa, i pot trigar desenes de microsegons, però amb les interrupcions habilitades, així que no bloqueja res.

Aquí resolem el problema que vam deixar plantejat. La clau és a igb_ring_irq_enable: mentre hi ha paquets per processar, les interrupcions d'aquella cua estan deshabilitades i el nucli consulta activament (sondeig).

NAPI és un híbrid adaptatiu: interrupcions amb càrrega baixa (latència mínima) i sondeig amb càrrega alta (rendiment màxim). Canvia de mode tot sol, sense configuració.

Els números per a Meteora:

És una de les solucions més elegants del nucli de Linux: reconèixer que cap de les dues tècniques de la lliçó anterior és sempre millor, i canviar-hi segons la càrrega.

Estructura d'una línia:

Anàlisi línia a línia del que diu aquest sistema:

El diagnòstic que salta a la vista: enp3s0-rx-0 concentra 1,28 milions d'interrupcions a CPU0 mentre els altres tres nuclis estan a zero. Amb 800 lectures/s no és cap problema, però és el coll d'ampolla que apareixeria en créixer.

La màscara 1 (binari 0001) significa «només CPU0». Per repartir-la:

I aquí apareix una decisió interessant que enllaça amb 02-02: a la lliçó de planificació vam confinar l'agregador als nuclis 2 i 3 amb taskset. Dirigir les interrupcions de xarxa a CPU0 i CPU1 completa aquesta partició: el processament de paquets i el càlcul de mitjanes deixen de competir tant per CPU com per memòria cau.

El dimoni irqbalance fa aquest repartiment automàticament, però en sistemes amb requisits de latència estrictes se sol desactivar per fixar l'afinitat a mà.

Observar l'activitat en temps real:

És la manera més ràpida de comprovar si un dispositiu està generant interrupcions. Si un dispositiu no respon i el seu comptador no augmenta, el problema és al maquinari o a l'encaminament de la interrupció, no al programari de dalt.

Les interrupcions clàssiques fan servir línies físiques: una pota dedicada del dispositiu a l'APIC. Això té tres problemes:

1. Escassetat: hi ha poques línies, d'aquí les compartides.
2. Condicions de cursa: el dispositiu pot afirmar la línia abans que les dades que ha escrit per DMA hagin arribat a la memòria. El gestor llegiria dades incompletes.
3. Un sol vector per dispositiu: no es pot distingir «he rebut un paquet» de «he acabat de transmetre».

MSI (Message Signaled Interrupts) elimina les línies: el dispositiu escriu un valor en una adreça de memòria especial, i aquesta escriptura és la interrupció.

Els dos avantatges decisius:

S'elimina la cursa amb el DMA. Com que la interrupció és una escriptura pel mateix bus PCIe que les dades, l'ordenació del bus garanteix que les dades ja han arribat quan arriba la interrupció. La línia física anava per un camí diferent i es podia avançar.

MSI-X permet un vector per cua i per nucli. Això és el que fa possible el repartiment perfecte de l'NVMe que vèiem més amunt:

Recorda de 02-05 que NVMe té fins a 65.535 cues i el seu avantatge és la paral·lelització. MSI-X és la peça que la completa: cada cua té el seu vector d'interrupció dirigit al seu propi nucli, així que no hi ha ni un forrellat compartit ni una CPU que centralitzi la feina.

Enable+ confirma que està actiu, i Count=5 que la targeta té 5 vectors: control, dues cues de recepció i dues de transmissió.

El DMA transfereix dades entre dispositiu i memòria sense CPU. Aquí hi ha com funciona per dins.

Les targetes modernes no reben una ordre per transferència: treballen amb anells de descriptors, estructures en memòria que la CPU omple i el dispositiu consumeix.

El cicle de vida:

Aquest disseny d'anell és el que permet rebre a màxima velocitat: la targeta pot escriure diversos paquets sense cap intervenció de la CPU, i el driver els recull en lot quan li toca. És la mateixa idea de la doble memòria intermèdia de 02-06, generalitzada a 256 posicions.

Aquí hi ha un problema subtil i molt real. La CPU té memòries cau; el DMA escriu directament a la RAM, saltant-se-les.

Les solucions, en ordre de preferència:

A x86 el maquinari és coherent i el problema no existeix. A ARM i altres arquitectures cal sincronitzar explícitament, i per això l'API de DMA de Linux és portable:

Fixa't en el concepte que expressen aquestes crides: la propietat de la memòria intermèdia es traspassa entre CPU i dispositiu. Mentre és del dispositiu, la CPU no l'ha de tocar, i a l'inrevés. És un patró que reapareixerà amb un altre nom al mòdul 3.

Un problema de seguretat de primer ordre: el DMA fa servir adreces físiques i se salta la MMU. Una targeta compromesa —o amb un microprogramari maliciós, o un dispositiu Thunderbolt connectat per un atacant— podria escriure a qualsevol adreça física, inclosa la memòria del nucli. És l'atac DMA, i s'ha explotat a la pràctica.

La IOMMU (Intel VT-d, AMD-Vi) és una MMU per a dispositius:

És exactament el mateix mecanisme que la MMU de 02-04 —taules de traducció, comprovació de permisos, fallada si no escau— però aplicat als dispositius en lloc dels processos. Cada dispositiu té el seu propi espai d'adreces de DMA i només pot accedir al que se li ha assignat.

A més de la seguretat, la IOMMU habilita el passthrough de dispositius a màquines virtuals: es pot donar una targeta física a una VM amb la garantia que el seu driver, encara que estigui compromès, no pot tocar la memòria de l'amfitrió ni de les altres VM. És una peça essencial de la virtualització, i tornarà a Virtualització: Hipervisors i Màquines Virtuals.

Ara sí, el recorregut complet sense caixes negres. Una estació envia una lectura de 24 bytes per UDP i l'ingestor la rep.

Recorregut pas a pas, amb el cost i la lliçó de referència:

Dues observacions que resumeixen el mòdul sencer:

La CPU intervé 12 µs per a un paquet que ha trigat 0,5 µs a arribar. El cost no és moure 66 bytes, sinó creuar capes: interrupció, canvi de context d'interrupció, pila de xarxa, despertar el procés, crida al sistema. És la mateixa lliçó del cost del syscall de 01-06 i del canvi de context de 02-01, aplicada a l'E/S.

El pas 11 és el que més varia. Els passos 1 a 10 són deterministes i sumen ~12 µs. El pas 11 depèn de la càrrega i del nice de l'ingestor, i pot ser zero o diversos mil·lisegons. La latència real està dominada per la planificació, no pel maquinari, i per això a 02-02 vam donar a l'ingestor prioritat elevada.

La latència d'interrupció és el temps des que el dispositiu la genera fins que comença a executar-se el gestor.

Els seus components:

El component crític és el tercer: si un altre codi del nucli té les interrupcions deshabilitades, la interrupció espera. Aquest és el pitjor cas, i és el que determina la previsibilitat del sistema.

Latència mitjana de 4 µs i màxima de 87 µs. Per a Meteora és excel·lent. Per a control industrial amb terminis de 50 µs, aquest màxim de 87 µs seria un incompliment.

PREEMPT_RT aconsegueix aquesta garantia convertint gairebé tots els gestors d'interrupció en fils del nucli planificables i substituint els spinlocks per mutex expropiables. Redueix el rendiment màxim a canvi de previsibilitat, que és exactament el compromís del temps real que vam plantejar a 01-03: predictible, no ràpid. El detall correspon a Sistemes Operatius Mòbils i de Temps Real.

Eines de diagnòstic:

rx_missed_errors i rx_no_buffer_count són les mètriques crítiques per a Meteora. Si són diferents de zero, s'estan perdent lectures: la targeta ha rebut paquets però no hi havia descriptors lliures on escriure'ls, perquè el driver no els va reciclar a temps. Com que les lectures perdudes són irrecuperables, aquestes dues xifres haurien d'estar monitorades amb alerta.

Passar de 256 a 2.048 descriptors dona al sistema vuit vegades més marge per absorbir ràfegues abans de perdre paquets. El cost és memòria (2.048 memòries intermèdies de 2 KB = 4 MB) i una mica més de latència en el pitjor cas. Per a un sistema on perdre dades és irreversible, és un intercanvi clarament favorable.

Fer feina pesada a la meitat superior. És l'error de disseny número u en drivers. Amb les interrupcions deshabilitades, tot el sistema espera. Un gestor que trigui 500 µs fa perdre paquets a la targeta de xarxa i provoca xruns a l'àudio. La regla: reconèixer el maquinari, desar el mínim, programar la meitat inferior, sortir.

Fer servir mutex_lock en context d'interrupció. Un mutex dorm, i en context atòmic dormir penja el sistema. Fes servir spin_lock_irqsave. I no oblidis l'irqsave: sense això, si la mateixa interrupció torna a entrar mentre tens el forrellat, et bloqueges contra tu mateix.

Oblidar l'EOI o el reconeixement al maquinari. El símptoma és inconfusible: el dispositiu funciona exactament una vegada i després es queda mut, o genera una tempesta infinita d'interrupcions que congela la màquina.

Retornar IRQ_HANDLED sense comprovar si la interrupció és teva. En una línia compartida, robes les interrupcions de l'altre dispositiu, que deixa de funcionar amb un símptoma impossible de relacionar amb el teu driver.

Fer servir memcpy en lloc de copy_to_user. És una vulnerabilitat d'escalada de privilegis, no un detall d'estil. El punter ve d'usuari i no és de fiar.

Ignorar rx_missed_errors. És la mètrica que diu si estàs perdent dades a la targeta. A Meteora, on les lectures perdudes són irrecuperables, hauria de tenir alerta configurada.

Desactivar irqbalance sense fixar l'afinitat a mà. Et quedes amb totes les interrupcions a CPU0, que és el pitjor dels dos móns: sense repartiment automàtic i sense repartiment manual.

Consell de diagnòstic: davant d'un dispositiu que no respon, l'ordre és: watch -n1 cat /proc/interrupts (genera interrupcions?), dmesg -T | tail -50 (hi ha errors del driver?), ethtool -S o l'eina equivalent (hi ha pèrdues?), cat /proc/irq/N/smp_affinity (estan totes en un nucli?). Si el comptador d'interrupcions no augmenta, el problema és per sota del driver: encaminament de la interrupció, MSI mal configurat o maquinari. Si augmenta però no arriben dades, el problema és per damunt.

Aquest és l'estat de meteo-01 durant el pic de les 8:00:

I en paral·lel:

1. Identifica el problema principal i justifica'l amb almenys tres dades de les dues sortides.
2. Per què LOC és 3,6 vegades més gran a CPU0 que als altres?
3. Què indica que nvme0q1 estigui repartit i enp3s0-rx-0 no?
4. Proposa una solució concreta amb les ordres exactes, i explica què milloraria cadascuna.
5. Com comprovaries si s'estan perdent lectures, i què faries si fos així?

Estàs escrivint el driver d'un dispositiu que recull dades d'un grup d'estacions connectades per un bus propietari. Quan arriba un lot de lectures, el driver ha de:

• (a) Llegir el registre d'estat del dispositiu. Triga 0,5 µs.
• (b) Reconèixer la interrupció escrivint en un registre. Triga 0,3 µs.
• (c) Copiar 64 lectures de 24 bytes des de la memòria intermèdia de DMA. Triga 8 µs.
• (d) Validar les sumes de comprovació de les 64 lectures. Triga 45 µs.
• (e) Reservar memòria per emmagatzemar-les. Pot necessitar dormir.
• (f) Escriure-les en un fitxer de /var/lib/meteora/lectures/. Triga mil·lisegons.
• (g) Despertar el procés que espera a read(). Triga 0,3 µs.

Respon:

1. Quines operacions van a la meitat superior i quines a la inferior? Justifica cadascuna.
2. Quin mecanisme de meitat inferior faries servir per a cada grup: softirq, tasklet o workqueue? Per què?
3. Calcula el temps amb les interrupcions deshabilitades en el teu disseny i compara'l amb fer-ho tot a la meitat superior.
4. Si el dispositiu genera 2.000 interrupcions per segon, calcula el percentatge de CPU en tots dos dissenys.
5. Què passaria si posessis (e) o (f) a la meitat superior?

L'equip de Meteora informa que falten lectures: les dades del dia tenen buits. Investigues i trobes:

1. Localitza on s'estan perdent els paquets. Hi ha almenys dos punts de pèrdua diferents: identifica'ls i explica en què es diferencien.
2. Calcula el percentatge de pèrdua i què significa en lectures perdudes al dia.
3. Proposa una solució completa per a cada punt de pèrdua, amb ordres concretes.
4. Hi ha un error de configuració evident a la sortida de ps. Identifica'l i corregeix-lo, relacionant-lo amb el que vam veure a 02-02.
5. Dissenya el monitoratge que hauria detectat això abans que l'equip se n'adonés.

Solució 1

1. El problema principal: CPU0 saturada pel processament de xarxa.

Les evidències:

El quadre és inequívoc: CPU0 està al 92 % d'ocupació mentre les altres tres estan a menys de la meitat. El sistema té capacitat de sobres en agregat (49,2 % d'%idle global) però un nucli és el coll d'ampolla.

I la dada que ho fa greu: si CPU0 se satura del tot, la softirq NET_RX no podrà buidar l'anell de descriptors a temps i es començaran a perdre lectures, que a Meteora és irreversible.

2. Per què LOC és 3,6 vegades més gran a CPU0.

LOC són les interrupcions del temporitzador local de l'APIC, que disparen la planificació. En un sistema amb NO_HZ (tickless), el temporitzador s'atura als nuclis ociosos per estalviar energia i només s'activa quan hi ha feina.

CPU0 té un 7,7 % d'%idle: està treballant gairebé tota l'estona, així que el seu temporitzador pràcticament no s'atura mai. Els altres tres, amb un 53-68 % d'inactivitat, passen llargs períodes sense ticks.

LOC alt no és la causa del problema: és un símptoma més que CPU0 no descansa.

3. nvme0q1 repartit davant d'enp3s0-rx-0 concentrat.

La diferència és l'arquitectura de cues, i és exactament el que vam veure a 02-05 i a l'apartat d'MSI-X:

NVMe: l'estàndard defineix una cua d'enviament i recepció per nucli. Cada cua té el seu vector MSI-X dirigit al seu nucli. Quan un procés a CPU2 fa E/S, fa servir la cua de CPU2 i la seva interrupció arriba a CPU2. Sense forrellats compartits i sense concentració.

El repartiment gairebé perfecte confirma que funciona com cal.

La targeta I210: només té una cua de recepció (rx-0, i ho confirma el Count=5 d'MSI-X: control, 2 RX, 2 TX en el millor cas, i aquí només se'n fa servir una). Tot el trànsit entrant hi passa, i el seu vector està dirigit a CPU0.

És una limitació combinada de maquinari i configuració, i per això les targetes de servidor modernes tenen múltiples cues RX amb RSS (Receive Side Scaling), que reparteix els fluxos entre cues segons un hash de les capçaleres.

4. Solució concreta.

a) Comprovar quantes cues admet la targeta:

Si n'admet 4, activar-les:

Què millora: la targeta passa a tenir 4 cues de recepció, cadascuna amb el seu vector MSI-X. Amb RSS, els paquets de fluxos diferents es reparteixen entre les quatre per hash, i cada cua interromp un nucli diferent. La feina de %soft es divideix per quatre.

b) Repartir l'afinitat de les interrupcions:

Què millora: garanteix el repartiment en lloc de deixar-lo a l'atzar.

c) Si la targeta només admet una cua, activar RPS per programari:

e és 1110 en binari: CPU1, CPU2 i CPU3. Què millora: RPS (Receive Packet Steering) fa en programari el que RSS fa en maquinari: la meitat superior continua executant-se a CPU0, però el processament de la pila de xarxa es distribueix als altres tres nuclis. S'exclou CPU0 deliberadament per descarregar-la.

d) Ajustar la moderació d'interrupcions:

Què millora: la targeta espera fins a 50 µs abans d'interrompre, agrupant diversos paquets per interrupció. Amb 8,4 milions d'interrupcions, agrupar-les de 10 en 10 les redueix a 840.000. El cost és fins a 50 µs més de latència per paquet, perfectament assumible a Meteora, on importa molt més no perdre lectures que lliurar-les 50 µs abans.

e) Coordinar-ho amb l'afinitat de processos de 02-02:

Què millora: que l'ingestor s'executi al mateix nucli on es processen els seus paquets aprofita la localitat de memòria cau: les dades del paquet ja són a la L1/L2 d'aquell nucli. És l'afinitat de processador de 02-02 aplicada a l'E/S.

5. Comprovar la pèrdua de lectures.

Interpretació de cada punt de pèrdua:

Si hi hagués pèrdues, l'actuació per ordre:

Solució 2

1. Repartiment entre meitats.

Discussió sobre (c), que és la decisió interessant: els 8 µs de còpia podrien anar en qualsevol de les dues. Arguments:

• A favor de la superior: si la memòria intermèdia de DMA és un anell petit, cal buidar-lo aviat perquè el dispositiu pugui continuar escrivint. Endarrerir-ho arrisca pèrdua de dades.
• A favor de la inferior: 8 µs són 16 vegades més que la resta de la meitat superior, i amb interrupcions deshabilitades és molt.

La resposta professional és no copiar en absolut. El disseny correcte fa servir un anell de descriptors com el de la targeta de xarxa: la meitat superior només anota quins descriptors estan llestos (avançant un índex, ~0,2 µs) i la meitat inferior processa les dades directament a la memòria intermèdia de DMA, sense copiar-les. És exactament el que fa igb_clean_rx_irq.

Disseny final:

2. Mecanisme per a cada grup.

Per a (d), validar sumes: tasklet.

• No necessita dormir: és càlcul pur sobre dades que ja són a la memòria.
• S'ha d'executar aviat: les dades ocupen la memòria intermèdia de DMA.
• No cal una softirq: les softirqs són un recurs escàs, amb un nombre fix compilat al nucli, reservat a subsistemes principals (xarxa, bloc, temporitzadors). Un driver concret fa servir tasklet, que està construïda sobre softirq i és la interfície pensada per a drivers.
• Avantatge addicional: una tasklet concreta no corre mai en dues CPU alhora, cosa que simplifica enormement la sincronització.

Per a (e), (f) i (g): workqueue, obligatòriament.

• (e) pot dormir. kmalloc(GFP_KERNEL) es bloqueja si no hi ha memòria lliure immediata, esperant que el nucli recuperi pàgines (tot el mecanisme de 02-04). En context atòmic això penja el sistema. La workqueue és l'única de les tres que pot dormir, perquè s'executa en un fil del nucli, és a dir, en context de procés amb el seu propi task_struct.
• (f) fa E/S de disc. Mil·lisegons de bloqueig. Impensable fora del context de procés.
• (g) ha d'anar després, així que acompanya les anteriors.

3. Temps amb interrupcions deshabilitades.

Disseny en dues meitats:

Tot a la meitat superior:

4. Percentatge de CPU amb 2.000 interrupcions/s.

Disseny en dues meitats:

(La workqueue fa E/S: el seu temps és majoritàriament espera de disc, no CPU.)

Tot a la meitat superior:

La mètrica que importa és la segona columna. El consum total gairebé no canvia: la feina s'ha de fer igualment. El que canvia radicalment és quant temps la resta del sistema està cega.

Amb el 10,8 % de les interrupcions deshabilitades, l'impacte a la resta de meteo-01 seria:

5. Si (e) o (f) anessin a la meitat superior.

Amb (e), kmalloc(GFP_KERNEL):

Si hi ha memòria lliure immediata, kmalloc retorna sense dormir i sembla que funcioni. Quan el sistema estigui sota pressió de memòria —justament quan més importa— intentarà dormir en context atòmic i el sistema es penjarà o entrarà en pànic. És el pitjor tipus de bug: funciona a les proves i falla en producció sota càrrega.

L'alternativa correcta si calgués reservar en context atòmic és GFP_ATOMIC, que no dorm mai però pot fallar més sovint i consumeix d'una reserva d'emergència. Tot i així, aquí la solució de disseny (workqueue) és millor.

Amb (f), escriure en un fitxer:

Encara pitjor. Escriure implica el sistema de fitxers, la memòria cau de pàgines, el planificador d'E/S de 02-05 i esperar el disc: mil·lisegons de bloqueig, amb múltiples punts on el codi dorm.

Conseqüències encadenades:

Conclusió general de l'exercici: la divisió en dues meitats no existeix per repartir feina, sinó per minimitzar la finestra en què el sistema no pot reaccionar al món exterior. Tot allò que no sigui imprescindible fer ara mateix ha de sortir de la meitat superior.

Solució 3

1. Els dos punts de pèrdua.

Punt 1: a la targeta de xarxa (maquinari).

La targeta va rebre els paquets correctament del cable però no tenia on posar-los: l'anell de 256 descriptors era ple perquè la softirq NET_RX no l'havia buidat a temps. Els paquets es van quedar al FIFO intern de la targeta fins a desbordar-lo.

Aquests paquets no van arribar mai a la RAM. El nucli no els va veure mai.

Punt 2: a la cua del backlog del nucli.

La columna 2 és zero, així que no se'n van descartar al backlog. Però la columna 3 és la reveladora: 167.745 vegades la softirq NET_RX va exhaurir el seu pressupost de temps o de paquets i va haver de cedir abans de buidar l'anell.

I aquí hi ha la connexió causal entre tots dos punts: un time_squeeze alt és la causa de rx_missed_errors. La softirq no pot seguir el ritme, l'anell no es buida, i la targeta perd paquets.

A més, la segona línia de softnet_stat (CPU1) mostra 18.962 paquets processats davant dels 16,9 milions de CPU0: tot el processament és en un nucli, el mateix problema de l'exercici 1.

Diferència entre tots dos punts:

La cua del socket (ss) mostra Recv-Q: 0, així que l'ingestor sí que llegeix a temps: no hi ha un tercer punt de pèrdua. El problema és anterior a l'aplicació.

2. Percentatge de pèrdua.

En lectures diàries:

285.811 lectures perdudes al dia, irrecuperables. Posat en context:

Un 0,41 % sembla poc, però per a mitjanes horàries per estació significa buits sistemàtics a les sèries, i en el pitjor cas una estació concreta podria perdre ratxes senceres si el seu trànsit coincideix amb els moments de desbordament.

3. Solució per a cada punt de pèrdua.

Per a la pèrdua a la targeta:

Per què funciona cadascuna:

• (a) Dona vuit vegades més marge per absorbir ràfegues. Amb 2.048 descriptors a 800 paquets/s, el sistema té 2,5 segons de coixí en lloc de 0,3. Costa 4 MB de RAM.
• (b) Reparteix la feina entre quatre nuclis, atacant la causa arrel.
• (c) Redueix les interrupcions agrupant paquets, i deixa més CPU per al processament real.

Per al time_squeeze:

• (d) netdev_budget és quants paquets processa la softirq abans de cedir. Pujar-lo de 300 a 600 redueix els time_squeeze a la meitat. El risc és que la softirq acapari més la CPU, així que convé pujar-lo amb moderació.
• (f) Reparteix el processament de la pila de xarxa a CPU1-3 encara que la interrupció continuï arribant a CPU0.

Fer-ho persistent:

4. L'error de configuració a ps.

Les prioritats estan invertides. L'agregador té prioritat elevada (−5) i l'ingestor prioritat normal (0). És exactament el contrari del que correspon, i contradiu el que vam establir a 02-02:

I això agreuja directament el problema de pèrdua. El raonament causal complet:

1. L'agregador amb nice −5 rep ~75 % de la CPU en conflicte (taula de pesos de 02-02).
2. És un procés limitat per CPU: quan s'executa, reté la CPU mil·lisegons sencers.
3. Les softirqs NET_RX competeixen amb ell per CPU0.
4. Endarrerir la softirq significa no buidar l'anell → time_squeeze → rx_missed_errors.
5. L'agregador mal prioritzat està causant pèrdua de lectures.

La correcció:

Persistent a systemd:

Això uneix les tres peces del mòdul: prioritat de CPU (02-02), afinitat de processador (02-02) i afinitat d'interrupcions (02-07), coordinades perquè el camí de les lectures —targeta → softirq → socket → ingestor— no competeixi amb el càlcul de mitjanes en cap punt.

5. Monitoratge que ho hauria detectat abans.

La fallada de procés aquí és tan greu com la tècnica: el problema el va detectar l'equip de dades en veure buits, no el sistema. Quan algú mira les sèries, ja s'han perdut lectures irrecuperables durant dies.

Mètriques i llindars:

El criteri clau: per a rx_missed_errors el llindar d'avís és qualsevol increment diferent de zero, perquè cada unitat és una lectura perduda per sempre. No és una mètrica de rendiment, és una mètrica de pèrdua de dades.

Script de recollida:

Comprovació d'extrem a extrem, la més valuosa:

Aquesta última és la que de debò importa: mesura el resultat, no els indicadors intermedis. Hi pot haver pèrdues en un punt que no estiguis vigilant —el commutador, el cable, la mateixa estació—, i només la comprovació d'extrem a extrem les detecta totes.

Es comparen bé així:

Un sistema de monitoratge decent té les tres: les de causa donen marge per actuar, les de símptoma localitzen el punt exacte, i la de resultat garanteix que no s'escapi res. Aquest plantejament el reprendrem a Monitoratge i Diagnòstic de Rendiment.

Un controlador de dispositiu és el programari que tradueix les operacions genèriques del nucli a les operacions concretes d'un model de maquinari, i són el 63 % del codi del nucli de Linux. Compleixen un contracte —una estructura de punters a funció com file_operations— que implementa polimorfisme en C: la mateixa read() acaba en codi diferent segons el major del dispositiu. Es carreguen com a mòduls l'alias dels quals connecta l'identificador PCI del maquinari amb el nom del mòdul, cosa que fa possible la càrrega automàtica. I viuen a l'anell 0, sense xarxa de seguretat: la traça Fatal exception in interrupt que hem llegit no acaba en un SIGSEGV, acaba en un kernel panic.

Una interrupció arriba per una línia IRQ, es tradueix en un vector i la CPU salta a l'entrada corresponent de la IDT, desant estat i canviant a la pila de nucli igual que en una crida al sistema. La diferència decisiva és que una interrupció no pertany a cap procés: s'executa sobre qui toqui, cosa que prohibeix dormir, bloquejar-se, reservar memòria amb GFP_KERNEL o tocar l'espai d'usuari. D'aquesta prohibició neix la divisió en meitat superior —microsegons, reconèixer el maquinari i programar feina— i meitat inferior —softirq, tasklet o workqueue, amb interrupcions habilitades—. A l'exercici n'hem mesurat la diferència: 1,1 µs davant de 54,1 µs de ceguesa del sistema, un factor de 49.

NAPI resol el problema que vam deixar plantejat a la lliçó anterior: alterna entre interrupcions amb càrrega baixa i sondeig amb càrrega alta, i redueix 65 vegades el cost a 500.000 paquets/s. MSI-X elimina les línies físiques, les curses amb el DMA i el límit d'un vector per dispositiu, i permet una cua d'interrupció per nucli —que és el que fa que nvme0q1 estigui perfectament repartit i enp3s0-rx-0 no—. El DMA treballa amb anells de descriptors que deixen que la targeta escrigui diversos paquets sense CPU, exigeix coordinar la coherència de memòria cau, i necessita la IOMMU perquè un dispositiu compromès no pugui escriure a qualsevol adreça física. I /proc/interrupts explica tota aquesta història línia a línia: qui interromp, quant i en quin nucli.

Amb això tanques el mòdul 2, i val la pena veure'n el recorregut complet. Vas començar obrint l'abstracció de procés (02-01): la seva imatge de memòria, el task_struct, els estats amb els seus codis reals, fork amb copy-on-write, execve, els zombis i el cost del canvi de context. Després vas veure com es reparteix la CPU entre ells (02-02): ràfegues, criteris en conflicte, els algorismes clàssics calculats a mà i el temps virtual just de CFS amb nice. Després el segon gran recurs, la memòria (02-03): adreces lògiques i físiques, la MMU, la fragmentació amb números i per què la paginació guanya; i el seu desenvolupament complet (02-04): traducció, taules multinivell, TLB, fallades de pàgina, reemplaçament, hiperpaginació, mmap i l'OOM killer. Després l'emmagatzematge (02-05): la física del disc i de l'SSD, la planificació de peticions i RAID. I per últim els dispositius (02-06): la uniformització, /dev, udev i les tres maneres de parlar amb el maquinari, que aquesta lliçó ha desenvolupat fins al final.

Les set lliçons responen a la mateixa pregunta des d'angles diferents: com es reparteix un recurs escàs entre molts que el volen. CPU, memòria, disc, dispositius. I en totes hi ha aparegut el mateix patró: una abstracció que amaga la complexitat, un mecanisme de maquinari que fa complir les regles, i una política del sistema operatiu que decideix.

Però hem donat per fet una cosa gran. Cada vegada que dos processos compartien una pàgina amb MAP_SHARED, cada vegada que una softirq i un procés tocaven la mateixa cua, cada vegada que dos treballadors de meteo-api escrivien a /dev/shm/meteora-cache, hem dit «això requereix sincronització» i hem tirat endavant. Ha arribat el moment de pagar aquest deute. Què passa exactament quan dos fluxos d'execució toquen la mateixa dada alhora? Per què comptador++ pot perdre increments? I com es coordinen sense destrossar el rendiment que tant ha costat aconseguir?

És el Mòdul 3: Concurrència, i comença a Conceptes de Concurrència.