Cerramos la lección anterior con tres cajas sin abrir y un problema planteado con números. Las cajas: qué hace exactamente la CPU cuando llega una interrupción, cómo un controlador se registra ante el núcleo y qué contrato cumple, y cómo funciona el DMA por dentro. El problema: a 500.000 lecturas por segundo, un núcleo entero se dedicaría solo a atender interrupciones, y eso no puede ser la solución final.

Esta lección abre las tres cajas y resuelve el problema. Vas a ver el recorrido completo de una interrupción desde la línea IRQ hasta el manejador, entender por qué el código de un manejador no puede dormir ni bloquearse, y por qué esa restricción obliga a partir el trabajo en dos mitades. Aprenderás a leer /proc/interrupts línea a línea, que es una de las salidas más informativas del sistema. Y seguirás el camino completo de un paquete con lecturas de estación, esta vez sin dejar ninguna capa sin explicar.

Es la última lección del módulo 2, así que al final recapitularemos las siete y enlazaremos con el módulo 3.

1. Qué es un controlador de dispositivo
2. El contrato con el núcleo: la interfaz de operaciones de fichero
3. Registro del driver y módulos cargables
4. Espacio de núcleo frente a espacio de usuario para drivers
5. Interrupciones: línea IRQ, vector y tabla de vectores
6. El controlador de interrupciones: del PIC al APIC
7. Qué hace la CPU al recibir una interrupción
8. El contexto de interrupción y sus reglas
9. Enmascaramiento e interrupciones compartidas
10. Mitad superior y mitad inferior
11. /proc/interrupts interpretado línea a línea
12. MSI y MSI-X
13. DMA en detalle: descriptores, coherencia e IOMMU
14. El camino completo de un paquete con lecturas
15. Latencia de interrupción y su impacto
16. Cierre del módulo 2

Un controlador de dispositivo (device driver) es el código que traduce las operaciones genéricas del núcleo en las operaciones concretas de un modelo de hardware.

Conviene distinguir dos cosas que en castellano comparten nombre y se confunden constantemente:

En esta lección, cuando digamos driver nos referimos al software; cuando digamos controlador del dispositivo o chip, al hardware.

El driver es la única pieza del sistema que conoce los detalles sucios: qué registro hay que escribir para iniciar una transferencia, en qué bit está la señal de "listo", cuántos microsegundos hay que esperar tras un reinicio, qué errata de silicio tiene la revisión B2 del chip.

Y su magnitud en el núcleo de Linux es reveladora:

Los drivers son el 63 % del código del núcleo. Y en el árbol de fuentes de Linux la proporción es similar: más de la mitad de los millones de líneas son controladores de dispositivo. El núcleo propiamente dicho —planificador, memoria, sistemas de archivos, red— es la parte pequeña.

Un driver no puede hacer lo que quiera: debe cumplir un contrato con el núcleo. Ese contrato es una estructura de punteros a función. Para un dispositivo de carácter:

Cómo funciona el mecanismo, que es el mismo despacho por tabla que vimos en 01-06 con las llamadas al sistema:

• Cuando un proceso llama a read() sobre /dev/meteora/estacion-norte, el núcleo recorre el camino que ya conoces: syscall → tabla de llamadas → sys_read → capa VFS.
• La capa VFS consulta el número mayor del fichero, encuentra el driver registrado y llama al puntero .read de su file_operations.
• Ese puntero apunta a meteora_read, código específico de este dispositivo.

Es polimorfismo implementado con punteros a función en C: la misma llamada read() acaba ejecutando código distinto según el dispositivo, sin que el código que llama sepa nada.

Los métodos habituales del contrato:

ioctl merece un comentario. Es la vía de escape del modelo "todo es un fichero": permite operaciones que no son leer ni escribir. Expulsar un CD, configurar la velocidad de un puerto serie, consultar estadísticas de una tarjeta. Que exista demuestra los límites de la abstracción de fichero, exactamente como los sockets demostraban los límites por otro lado. ioctl es el reconocimiento pragmático de que no todo cabe en read/write.

Un esqueleto de driver simplificado:

Puntos que hay que entender de este código:

• copy_to_user() en lugar de memcpy(). Es obligatorio y no es una formalidad. El puntero buf viene del espacio de usuario y no es de fiar: podría apuntar a memoria del núcleo, a una dirección no mapeada o a memoria de otro proceso. copy_to_user valida el rango, gestiona el fallo de página si la página no está presente, y devuelve el número de bytes que no pudo copiar. Un memcpy directo sería una vulnerabilidad de escalada de privilegios de manual. La marca __user en el prototipo permite además que herramientas de análisis estático detecten el error.
• Devolver -EIO y -EFAULT, en negativo. Ese es exactamente el convenio que rastreamos en 01-06: el núcleo devuelve el error como un valor negativo pequeño, y la biblioteca C lo convierte en -1 más errno.
• register_chrdev con mayor 0 pide al núcleo que asigne un número libre. Fijar un mayor a mano solo funciona para los números reservados oficialmente.
• module_init y module_exit definen los puntos de entrada y salida del módulo, que es lo que hace posible cargarlo y descargarlo en caliente.

Retomamos aquí lo de 01-05: los módulos cargables permiten añadir código al núcleo en ejecución.

La línea alias es la clave de la carga automática: dice que este módulo gestiona el dispositivo PCI con fabricante 8086 (Intel) y dispositivo 1521 (I350). Cuando el bus PCI enumera una tarjeta con esos identificadores, udev busca un módulo con el alias correspondiente y lo carga sin intervención humana.

Ahí está la cadena completa: el identificador del hardware conduce al nombre del módulo.

Ventajas de los módulos, retomando la discusión de arquitectura del núcleo de 01-05:

Y una limitación importante: un módulo se ejecuta con todos los privilegios del núcleo. No hay aislamiento. Un módulo con un fallo puede corromper cualquier estructura del sistema.

Aquí retomamos y cerramos el debate de arquitecturas de 01-05, ahora con datos concretos.

Por qué un driver defectuoso es peligroso. Un driver corre en anillo 0, así que:

• Puede escribir en cualquier dirección de memoria física, incluidas las estructuras del núcleo y la memoria de cualquier proceso.
• Puede ejecutar instrucciones privilegiadas: deshabilitar interrupciones, cambiar la tabla de páginas, reprogramar la MMU.
• No hay MMU que lo proteja de sí mismo: los mecanismos de protección que estudiamos en 02-03 y 02-04 protegen los procesos entre sí, pero el núcleo está por encima de ellos.

Un puntero nulo en un driver:

Cómo se lee esta traza:

• supervisor read access in kernel mode: el fallo ocurrió en anillo 0. Si hubiera sido en usuario, sería un simple SIGSEGV.
• RIP: meteora_interrupt_handler+0x2a [meteora_drv]: la dirección exacta donde falló, con el módulo culpable identificado entre corchetes.
• Tainted: G O: el núcleo está "contaminado" por un módulo externo. Los desarrolladores del núcleo usan esta marca para saber que el problema puede no ser suyo.
• Fatal exception in interrupt: y aquí está lo grave. El fallo ocurrió dentro de un manejador de interrupción, donde el núcleo no puede simplemente matar el proceso responsable (no hay proceso: Comm: swapper/2 es el hilo ocioso). No hay recuperación posible: kernel panic.

Compara con el mismo error en meteo-api: muere un proceso, systemd lo reinicia, se pierden unas peticiones. Aquí muere la máquina entera.

Drivers en espacio de usuario. La alternativa existe y se usa en casos concretos:

El caso de DPDK es paradójico y muy instructivo: mueve el driver a espacio de usuario no por seguridad, sino por rendimiento. Mapea los registros de la tarjeta directamente en el proceso y hace polling continuo, eliminando interrupciones y llamadas al sistema. Consigue procesar millones de paquetes por segundo a costa de dedicar núcleos completos a girar en un bucle. Es exactamente la espera activa de la lección anterior, elegida deliberadamente porque a esas tasas resulta más barata que interrumpir.

Una interrupción es una señal del hardware que hace que la CPU suspenda lo que está haciendo y ejecute un código predeterminado.

El vocabulario, que hay que tener claro:

En x86-64 hay 256 vectores, repartidos así:

Algunos vectores de excepción que ya conoces por lecciones anteriores:

Y aquí conviene fijar una clasificación que se confunde a menudo:

La diferencia clave es la sincronía. Una excepción ocurre siempre en el mismo punto si repites el programa con los mismos datos: es consecuencia de la instrucción que se estaba ejecutando. Una interrupción llega cuando le da la gana al mundo exterior y puede caer entre dos instrucciones cualesquiera. Esa asincronía es la fuente de toda la dificultad del código de interrupciones.

La IDT vive en memoria y su dirección está en el registro IDTR, cargado con la instrucción privilegiada lidt que vimos en la tabla de 01-06. Cada entrada contiene la dirección del manejador, el segmento y los permisos.

La CPU tiene muy pocas patillas de interrupción, así que hace falta un chip intermediario que multiplexe las líneas de todos los dispositivos.

PIC 8259A (1976): dos chips encadenados, 15 líneas IRQ útiles.

Esa asignación de 1981 sigue reconociéndose hoy en /proc/interrupts.

APIC (Advanced Programmable Interrupt Controller) lo sustituyó, y sus mejoras son las que hacen viable un servidor multiprocesador:

El APIC tiene dos partes:

• Local APIC: uno por núcleo, integrado en la CPU. Recibe las interrupciones dirigidas a ese núcleo y gestiona el temporizador local y las interrupciones entre procesadores.
• I/O APIC: en el chipset. Recibe las líneas de los dispositivos y las encamina al Local APIC del núcleo que corresponda.

Que el APIC pueda dirigir una interrupción a un núcleo concreto es lo que permite el smp_affinity que veremos al hablar de /proc/interrupts, y lo que hace posible que una tarjeta con varias colas reparta su trabajo entre núcleos.

Este es el recorrido exacto, y conviene compararlo mentalmente con el de la llamada al sistema de 01-06:

Los detalles que importan:

1. La instrucción en curso se termina. La CPU no interrumpe a mitad de una instrucción (con contadas excepciones para instrucciones muy largas, que son reanudables). Esto garantiza un estado consistente.
2. Se guarda el estado mínimo automáticamente: puntero de instrucción, puntero de pila, registro de banderas y selector de segmento. Lo hace el hardware, no el software.
3. Se cambia a la pila de núcleo, exactamente como en un syscall. El manejador nunca usa la pila del proceso interrumpido.
4. Las interrupciones se deshabilitan si la entrada de la IDT es una interrupt gate (lo habitual). Esto evita que otra interrupción anide inmediatamente.
5. El EOI es obligatorio. Si el manejador no envía la señal de fin de interrupción al APIC, ese dispositivo no volverá a interrumpir jamás. Es uno de los errores clásicos al escribir drivers, y su síntoma es que el dispositivo funciona exactamente una vez y luego se queda mudo.

Comparación con lo que ya sabes:

La fila crucial es la penúltima: una llamada al sistema se ejecuta en nombre de un proceso concreto, mientras que una interrupción se ejecuta en el contexto de quien tocara estar ejecutándose, que puede ser cualquiera. De ahí salen todas las restricciones del apartado siguiente.

Un manejador de interrupción se ejecuta en contexto de interrupción, también llamado contexto atómico. Es un entorno con reglas muy estrictas:

Comprender el porqué de la primera regla es la clave de todo lo demás. Cuando el ingestor llama a read() y no hay datos, el núcleo lo pone en estado S y planifica otro proceso: hay un task_struct al que aparcar. Pero un manejador de interrupción no pertenece a ningún proceso. Si se durmiera, ¿a quién se pondría en estado S? ¿Al proceso que casualmente estaba ejecutándose, que no tiene nada que ver? ¿Y quién lo despertaría?

Recuerda la traza del kernel panic: Comm: swapper/2. El manejador se ejecutó "sobre" el hilo ocioso, que era lo que había en ese núcleo. No era su interrupción ni su trabajo.

Las cuatro decisiones del manejador correcto:

1. Comprobar si la interrupción es suya antes de nada, porque la línea puede estar compartida. Devolver IRQ_NONE permite que el núcleo pruebe con el siguiente driver registrado.
2. Reconocerla en el hardware escribiendo en el registro de estado. Sin esto, el dispositivo seguiría afirmando la línea y se generaría una tormenta de interrupciones infinita.
3. spin_lock_irqsave en lugar de mutex_lock. Un mutex duerme si está ocupado; un spinlock gira esperando, que es lo único que puede hacerse en contexto atómico. La variante irqsave guarda además el estado de las interrupciones y las deshabilita, evitando el interbloqueo consigo mismo si la misma interrupción se repitiera.
4. Delegar todo el trabajo real a la mitad inferior. Solo se ha incrementado un contador y programado trabajo diferido.

Enmascaramiento es deshabilitar temporalmente una interrupción, y hay tres niveles:

cli es la instrucción privilegiada que probamos en 01-06 y que provocaba un SIGSEGV en modo usuario. Ahora entiendes por qué debe ser privilegiada con tanta rotundidad: un proceso que pudiera deshabilitar las interrupciones impediría que el temporizador se las quitara, monopolizando la CPU para siempre y rompiendo por completo la planificación apropiativa de 02-02.

Las NMI (Non-Maskable Interrupt) no se pueden enmascarar bajo ningún concepto. Se reservan para fallos catastróficos: error de paridad de memoria, el temporizador de vigilancia, señales de fallo de hardware. Si el sistema deja de responder por completo, la NMI del watchdog es la que fuerza un volcado de diagnóstico.

Interrupciones compartidas. Con pocas líneas IRQ y muchos dispositivos, varios pueden compartir línea:

La IRQ 16 la comparten el controlador USB y el bus SMBus. Cuando se activa, el núcleo no sabe cuál de los dos ha sido, así que llama a los manejadores de todos los drivers registrados en esa línea, en orden, hasta que uno devuelve IRQ_HANDLED.

De ahí la importancia de la comprobación del apartado anterior: un driver que devolviera IRQ_HANDLED sin comprobar si la interrupción era suya robaría las interrupciones del otro dispositivo, que dejaría de funcionar con un síntoma imposible de diagnosticar.

El último argumento es esencial en líneas compartidas: es lo que permite que el manejador sepa a qué instancia de dispositivo corresponde la llamada.

Aquí está la idea central del diseño de interrupciones en Linux, y resuelve una tensión real.

La tensión: un manejador de interrupción debe ser rapidísimo, porque se ejecuta con interrupciones deshabilitadas y bloquea todo lo demás. Pero el trabajo que genera una interrupción puede ser considerable: procesar un paquete de red implica recorrer la pila IP, buscar el socket, actualizar estadísticas, despertar procesos.

La solución: partirlo en dos.

Los tres mecanismos de mitad inferior en Linux:

• softirq: la más rápida y la única que escala. Hay un número fijo definido en tiempo de compilación, así que solo la usan los subsistemas principales del núcleo. La misma softirq puede ejecutarse simultáneamente en varias CPU, lo que exige que su código sea reentrante.
• tasklet: construida sobre softirq, más fácil de usar. Una tasklet concreta nunca se ejecuta en dos CPU a la vez, lo que simplifica la sincronización a costa de escalabilidad.
• workqueue: ejecuta en un hilo del núcleo, es decir, en contexto de proceso. Es la única que puede dormir, así que es la opción cuando hace falta reservar memoria con GFP_KERNEL, esperar un mutex o hacer E/S.

Lectura de esta salida:

• NET_RX es 30 veces mayor en CPU0 (1.284.102 frente a ~40.000). Todo el tráfico de red entrante se procesa en un solo núcleo. Con una tarjeta de una sola cola es lo esperable; con una multicola, indica que la afinidad de interrupciones no está bien repartida.
• TIMER está repartido uniformemente, como debe ser: cada núcleo tiene su temporizador local del APIC.
• BLOCK son las interrupciones de dispositivos de bloque completadas, correlacionadas con la actividad del RAID que vimos en 02-05.

El reparto es claro: la mitad superior tarda menos de 1 µs y solo programa trabajo. La mitad inferior procesa hasta 64 paquetes recorriendo toda la pila de red, y puede tardar decenas de microsegundos, pero con las interrupciones habilitadas, así que no bloquea nada.

Aquí resolvemos el problema que dejamos planteado. La clave está en igb_ring_irq_enable: mientras hay paquetes que procesar, las interrupciones de esa cola están deshabilitadas y el núcleo consulta activamente (polling).

NAPI es un híbrido adaptativo: interrupciones con carga baja (latencia mínima) y polling con carga alta (rendimiento máximo). Cambia de modo solo, sin configuración.

Los números para Meteora:

Es una de las soluciones más elegantes del núcleo de Linux: reconocer que ninguna de las dos técnicas de la lección anterior es siempre mejor, y cambiar entre ellas según la carga.

Estructura de una línea:

Análisis línea a línea de lo que dice este sistema:

El diagnóstico que salta a la vista: enp3s0-rx-0 concentra 1,28 millones de interrupciones en CPU0 mientras los otros tres núcleos están a cero. Con 800 lecturas/s no es problema, pero es el cuello de botella que aparecería al crecer.

La máscara 1 (binario 0001) significa "solo CPU0". Para repartir:

Y ahí aparece una decisión interesante que enlaza con 02-02: en la lección de planificación confinamos el agregador a los núcleos 2 y 3 con taskset. Dirigir las interrupciones de red a CPU0 y CPU1 completa esa partición: el procesamiento de paquetes y el cálculo de medias dejan de competir tanto por CPU como por caché.

El demonio irqbalance hace este reparto automáticamente, pero en sistemas con requisitos de latencia estrictos suele desactivarse para fijar la afinidad a mano.

Observar la actividad en tiempo real:

Es la forma más rápida de comprobar si un dispositivo está generando interrupciones. Si un dispositivo no responde y su contador no aumenta, el problema está en el hardware o en el encaminamiento de la interrupción, no en el software de arriba.

Las interrupciones clásicas usan líneas físicas: una patilla dedicada del dispositivo al APIC. Eso tiene tres problemas:

1. Escasez: hay pocas líneas, de ahí las compartidas.
2. Condiciones de carrera: el dispositivo puede afirmar la línea antes de que los datos que ha escrito por DMA hayan llegado a la memoria. El manejador leería datos incompletos.
3. Un solo vector por dispositivo: no se puede distinguir "he recibido un paquete" de "he terminado de transmitir".

MSI (Message Signaled Interrupts) elimina las líneas: el dispositivo escribe un valor en una dirección de memoria especial, y esa escritura es la interrupción.

Las dos ventajas decisivas:

Se elimina la carrera con el DMA. Como la interrupción es una escritura por el mismo bus PCIe que los datos, el ordenamiento del bus garantiza que los datos ya han llegado cuando llega la interrupción. La línea física iba por un camino distinto y podía adelantarse.

MSI-X permite un vector por cola y por núcleo. Eso es lo que hace posible el reparto perfecto del NVMe que veíamos arriba:

Recuerda de 02-05 que NVMe tiene hasta 65.535 colas y su ventaja es la paralelización. MSI-X es la pieza que la completa: cada cola tiene su vector de interrupción dirigido a su propio núcleo, así que no hay ni un cerrojo compartido ni una CPU que centralice el trabajo.

Enable+ confirma que está activo, y Count=5 que la tarjeta tiene 5 vectores: control, dos colas de recepción y dos de transmisión.

El DMA transfiere datos entre dispositivo y memoria sin CPU. Aquí está cómo funciona por dentro.

Las tarjetas modernas no reciben una orden por transferencia: trabajan con anillos de descriptores, estructuras en memoria que la CPU rellena y el dispositivo consume.

El ciclo de vida:

Este diseño de anillo es lo que permite recibir a máxima velocidad: la tarjeta puede escribir varios paquetes sin ninguna intervención de la CPU, y el driver los recoge en lote cuando le toca. Es la misma idea del doble búfer de 02-06, generalizada a 256 posiciones.

Aquí hay un problema sutil y muy real. La CPU tiene cachés; el DMA escribe directamente en la RAM, saltándoselas.

Las soluciones, en orden de preferencia:

En x86 el hardware es coherente y el problema no existe. En ARM y otras arquitecturas hay que sincronizar explícitamente, y por eso la API de DMA de Linux es portable:

Fíjate en el concepto que expresan estas llamadas: la propiedad del búfer se traspasa entre CPU y dispositivo. Mientras es del dispositivo, la CPU no debe tocarlo, y viceversa. Es un patrón que reaparecerá con otro nombre en el módulo 3.

Un problema de seguridad de primer orden: el DMA usa direcciones físicas y se salta la MMU. Una tarjeta comprometida —o con un firmware malicioso, o un dispositivo Thunderbolt conectado por un atacante— podría escribir en cualquier dirección física, incluida la memoria del núcleo. Es el ataque DMA, y ha sido explotado en la práctica.

La IOMMU (Intel VT-d, AMD-Vi) es una MMU para dispositivos:

Es exactamente el mismo mecanismo que la MMU de 02-04 —tablas de traducción, comprobación de permisos, fallo si no procede— pero aplicado a los dispositivos en lugar de a los procesos. Cada dispositivo tiene su propio espacio de direcciones de DMA y solo puede acceder a lo que se le ha asignado.

Además de la seguridad, la IOMMU habilita el passthrough de dispositivos a máquinas virtuales: se puede dar una tarjeta física a una VM con la garantía de que su driver, aunque esté comprometido, no puede tocar la memoria del anfitrión ni de las otras VM. Es una pieza esencial de la virtualización, y volverá en Virtualización: Hipervisores y Máquinas Virtuales.

Ahora sí, el recorrido completo sin cajas negras. Una estación envía una lectura de 24 bytes por UDP y el ingestor la recibe.

Recorrido paso a paso, con el coste y la lección de referencia:

Dos observaciones que resumen el módulo entero:

La CPU interviene 12 µs para un paquete que tardó 0,5 µs en llegar. El coste no está en mover 66 bytes, sino en cruzar capas: interrupción, cambio de contexto de interrupción, pila de red, despertar del proceso, llamada al sistema. Es la misma lección del coste del syscall de 01-06 y del cambio de contexto de 02-01, aplicada a la E/S.

El paso 11 es el que más varía. Los pasos 1 a 10 son deterministas y suman ~12 µs. El paso 11 depende de la carga y del nice del ingestor, y puede ser cero o varios milisegundos. La latencia real está dominada por la planificación, no por el hardware, y por eso en 02-02 le dimos al ingestor prioridad elevada.

La latencia de interrupción es el tiempo desde que el dispositivo la genera hasta que empieza a ejecutarse el manejador.

Sus componentes:

El componente crítico es el tercero: si otro código del núcleo tiene las interrupciones deshabilitadas, la interrupción espera. Ese es el peor caso, y es lo que determina la previsibilidad del sistema.

Latencia media de 4 µs y máxima de 87 µs. Para Meteora es excelente. Para control industrial con plazos de 50 µs, ese máximo de 87 µs sería un incumplimiento.

PREEMPT_RT consigue esa garantía convirtiendo casi todos los manejadores de interrupción en hilos del núcleo planificables y sustituyendo los spinlocks por mutex apropiables. Reduce el rendimiento máximo a cambio de previsibilidad, que es exactamente el compromiso del tiempo real que planteamos en 01-03: predecible, no rápido. El detalle corresponde a Sistemas Operativos Móviles y de Tiempo Real.

Herramientas de diagnóstico:

rx_missed_errors y rx_no_buffer_count son las métricas críticas para Meteora. Si son distintas de cero, se están perdiendo lecturas: la tarjeta recibió paquetes pero no había descriptores libres donde escribirlos, porque el driver no los recicló a tiempo. Como las lecturas perdidas son irrecuperables, estas dos cifras deberían estar monitorizadas con alerta.

Pasar de 256 a 2.048 descriptores da al sistema ocho veces más margen para absorber ráfagas antes de perder paquetes. El coste es memoria (2.048 búferes de 2 KB = 4 MB) y algo más de latencia en el peor caso. Para un sistema donde perder datos es irreversible, es un intercambio claramente favorable.

Hacer trabajo pesado en la mitad superior. Es el error de diseño número uno en drivers. Con las interrupciones deshabilitadas, todo el sistema espera. Un manejador que tarde 500 µs hace perder paquetes a la tarjeta de red y provoca xruns en el audio. La regla: reconocer el hardware, guardar lo mínimo, programar la mitad inferior, salir.

Usar mutex_lock en contexto de interrupción. Un mutex duerme, y en contexto atómico dormir cuelga el sistema. Usa spin_lock_irqsave. Y no olvides irqsave: sin él, si la misma interrupción vuelve a entrar mientras tienes el cerrojo, te bloqueas contra ti mismo.

Olvidar el EOI o el reconocimiento en el hardware. El síntoma es inconfundible: el dispositivo funciona exactamente una vez y luego se queda mudo, o genera una tormenta infinita de interrupciones que congela la máquina.

Devolver IRQ_HANDLED sin comprobar si la interrupción es tuya. En una línea compartida, robas las interrupciones del otro dispositivo, que deja de funcionar con un síntoma imposible de relacionar con tu driver.

Usar memcpy en lugar de copy_to_user. Es una vulnerabilidad de escalada de privilegios, no un detalle de estilo. El puntero viene de usuario y no es de fiar.

Ignorar rx_missed_errors. Es la métrica que dice si estás perdiendo datos en la tarjeta. En Meteora, donde las lecturas perdidas son irrecuperables, debería tener alerta configurada.

Desactivar irqbalance sin fijar la afinidad a mano. Te quedas con todas las interrupciones en CPU0, que es el peor de los dos mundos: sin reparto automático y sin reparto manual.

Consejo de diagnóstico: ante un dispositivo que no responde, el orden es: watch -n1 cat /proc/interrupts (¿genera interrupciones?), dmesg -T | tail -50 (¿hay errores del driver?), ethtool -S o la herramienta equivalente (¿hay pérdidas?), cat /proc/irq/N/smp_affinity (¿están todas en un núcleo?). Si el contador de interrupciones no aumenta, el problema está por debajo del driver: encaminamiento de la interrupción, MSI mal configurado o hardware. Si aumenta pero no llegan datos, el problema está por encima.

Este es el estado de meteo-01 durante el pico de las 8:00:

Y en paralelo:

1. Identifica el problema principal y justifícalo con al menos tres datos de las dos salidas.
2. ¿Por qué LOC es 3,6 veces mayor en CPU0 que en los demás?
3. ¿Qué indica que nvme0q1 esté repartido y enp3s0-rx-0 no?
4. Propón una solución concreta con las órdenes exactas, y explica qué mejoraría cada una.
5. ¿Cómo comprobarías si se están perdiendo lecturas, y qué harías si así fuera?

Estás escribiendo el driver de un dispositivo que recoge datos de un grupo de estaciones conectadas por un bus propietario. Cuando llega un lote de lecturas, el driver debe:

• (a) Leer el registro de estado del dispositivo. Tarda 0,5 µs.
• (b) Reconocer la interrupción escribiendo en un registro. Tarda 0,3 µs.
• (c) Copiar 64 lecturas de 24 bytes desde el búfer DMA. Tarda 8 µs.
• (d) Validar las sumas de comprobación de las 64 lecturas. Tarda 45 µs.
• (e) Reservar memoria para almacenarlas. Puede necesitar dormir.
• (f) Escribirlas en un fichero de /var/lib/meteora/lecturas/. Tarda milisegundos.
• (g) Despertar al proceso que espera en read(). Tarda 0,3 µs.

Responde:

1. ¿Qué operaciones van en la mitad superior y cuáles en la inferior? Justifica cada una.
2. ¿Qué mecanismo de mitad inferior usarías para cada grupo: softirq, tasklet o workqueue? ¿Por qué?
3. Calcula el tiempo con las interrupciones deshabilitadas en tu diseño y compáralo con hacerlo todo en la mitad superior.
4. Si el dispositivo genera 2.000 interrupciones por segundo, calcula el porcentaje de CPU en ambos diseños.
5. ¿Qué pasaría si pusieras (e) o (f) en la mitad superior?

El equipo de Meteora informa de que faltan lecturas: los datos del día tienen huecos. Investigas y encuentras:

1. Localiza dónde se están perdiendo los paquetes. Hay al menos dos puntos de pérdida distintos: identifícalos y explica en qué se diferencian.
2. Calcula el porcentaje de pérdida y qué significa en lecturas perdidas al día.
3. Propón una solución completa para cada punto de pérdida, con órdenes concretas.
4. Hay un error de configuración evidente en la salida de ps. Identifícalo y corrígelo, relacionándolo con lo visto en 02-02.
5. Diseña la monitorización que habría detectado esto antes de que el equipo se diera cuenta.

Solución 1

1. El problema principal: CPU0 saturada por el procesamiento de red.

Las evidencias:

El cuadro es inequívoco: CPU0 está al 92 % de ocupación mientras las otras tres están a menos de la mitad. El sistema tiene capacidad de sobra en agregado (49,2 % de %idle global) pero un núcleo es el cuello de botella.

Y el dato que lo hace grave: si CPU0 se satura del todo, la softirq NET_RX no podrá vaciar el anillo de descriptores a tiempo y se empezarán a perder lecturas, que en Meteora es irreversible.

2. Por qué LOC es 3,6 veces mayor en CPU0.

LOC son las interrupciones del temporizador local del APIC, que disparan la planificación. En un sistema con NO_HZ (tickless), el temporizador se detiene en los núcleos ociosos para ahorrar energía y solo se activa cuando hay trabajo.

CPU0 tiene un 7,7 % de %idle: está trabajando casi todo el tiempo, así que su temporizador prácticamente nunca se detiene. Los otros tres, con 53-68 % de inactividad, pasan largos periodos sin ticks.

LOC alto no es la causa del problema: es un síntoma más de que CPU0 no descansa.

3. nvme0q1 repartido frente a enp3s0-rx-0 concentrado.

La diferencia está en la arquitectura de colas, y es exactamente lo que vimos en 02-05 y en el apartado de MSI-X:

NVMe: el estándar define una cola de envío y recepción por núcleo. Cada cola tiene su vector MSI-X dirigido a su núcleo. Cuando un proceso en CPU2 hace E/S, usa la cola de CPU2 y su interrupción llega a CPU2. Sin cerrojos compartidos y sin concentración.

El reparto casi perfecto confirma que funciona como debe.

La tarjeta I210: solo tiene una cola de recepción (rx-0, y lo confirma el Count=5 de MSI-X: control, 2 RX, 2 TX en el mejor caso, y aquí solo se usa una). Todo el tráfico entrante pasa por ella, y su vector está dirigido a CPU0.

Es una limitación combinada de hardware y configuración, y por eso las tarjetas de servidor modernas tienen múltiples colas RX con RSS (Receive Side Scaling), que reparte los flujos entre colas según un hash de las cabeceras.

4. Solución concreta.

a) Comprobar cuántas colas soporta la tarjeta:

Si soporta 4, activarlas:

Qué mejora: la tarjeta pasa a tener 4 colas de recepción, cada una con su vector MSI-X. Con RSS, los paquetes de distintos flujos se reparten entre las cuatro por hash, y cada cola interrumpe a un núcleo distinto. El trabajo de %soft se divide por cuatro.

b) Repartir la afinidad de las interrupciones:

Qué mejora: garantiza el reparto en lugar de dejarlo al azar.

c) Si la tarjeta solo soporta una cola, activar RPS por software:

e es 1110 en binario: CPU1, CPU2 y CPU3. Qué mejora: RPS (Receive Packet Steering) hace en software lo que RSS hace en hardware: la mitad superior sigue ejecutándose en CPU0, pero el procesamiento de la pila de red se distribuye a los otros tres núcleos. Se excluye CPU0 deliberadamente para descargarla.

d) Ajustar la moderación de interrupciones:

Qué mejora: la tarjeta espera hasta 50 µs antes de interrumpir, agrupando varios paquetes por interrupción. Con 8,4 millones de interrupciones, agrupar de 10 en 10 las reduce a 840.000. El coste es hasta 50 µs más de latencia por paquete, perfectamente asumible en Meteora, donde importa no perder lecturas mucho más que entregarlas 50 µs antes.

e) Coordinar con la afinidad de procesos de 02-02:

Qué mejora: que el ingestor se ejecute en el mismo núcleo donde se procesan sus paquetes aprovecha la localidad de caché: los datos del paquete ya están en la L1/L2 de ese núcleo. Es la afinidad de procesador de 02-02 aplicada a la E/S.

5. Comprobar pérdida de lecturas.

Interpretación de cada punto de pérdida:

Si hubiera pérdidas, la actuación por orden:

Solución 2

1. Reparto entre mitades.

Discusión sobre (c), que es la decisión interesante: los 8 µs de copia podrían ir en cualquiera de las dos. Argumentos:

• A favor de la superior: si el búfer DMA es un anillo pequeño, hay que vaciarlo pronto para que el dispositivo pueda seguir escribiendo. Retrasarlo arriesga pérdida de datos.
• A favor de la inferior: 8 µs son 16 veces más que el resto de la mitad superior, y con interrupciones deshabilitadas es mucho.

La respuesta profesional es no copiar en absoluto. El diseño correcto usa un anillo de descriptores como el de la tarjeta de red: la mitad superior solo anota qué descriptores están listos (avanzando un índice, ~0,2 µs) y la mitad inferior procesa los datos directamente en el búfer DMA, sin copiarlos. Es exactamente lo que hace igb_clean_rx_irq.

Diseño final:

2. Mecanismo para cada grupo.

Para (d), validar sumas: tasklet.

• No necesita dormir: es cálculo puro sobre datos ya en memoria.
• Debe ejecutarse pronto: los datos ocupan el búfer DMA.
• No hace falta softirq: las softirqs son un recurso escaso, con un número fijo compilado en el núcleo, reservado a subsistemas principales (red, bloque, temporizadores). Un driver concreto usa tasklet, que está construida sobre softirq y es la interfaz pensada para drivers.
• Ventaja adicional: una tasklet concreta nunca corre en dos CPU a la vez, lo que simplifica enormemente la sincronización.

Para (e), (f) y (g): workqueue, obligatoriamente.

• (e) puede dormir. kmalloc(GFP_KERNEL) se bloquea si no hay memoria libre inmediata, esperando a que el núcleo recupere páginas (todo el mecanismo de 02-04). En contexto atómico eso cuelga el sistema. La workqueue es la única de las tres que puede dormir, porque se ejecuta en un hilo del núcleo, es decir, en contexto de proceso con su propio task_struct.
• (f) hace E/S de disco. Milisegundos de bloqueo. Impensable fuera de contexto de proceso.
• (g) debe ir después, así que acompaña a las anteriores.

3. Tiempo con interrupciones deshabilitadas.

Diseño en dos mitades:

Todo en la mitad superior:

4. Porcentaje de CPU con 2.000 interrupciones/s.

Diseño en dos mitades:

(La workqueue hace E/S: su tiempo es mayoritariamente espera de disco, no CPU.)

Todo en la mitad superior:

La métrica que importa es la segunda columna. El consumo total apenas cambia: el trabajo hay que hacerlo igualmente. Lo que cambia radicalmente es cuánto tiempo el resto del sistema está ciego.

Con el 10,8 % de las interrupciones deshabilitadas, el impacto en el resto de meteo-01 sería:

5. Si (e) o (f) fueran a la mitad superior.

Con (e), kmalloc(GFP_KERNEL):

Si hay memoria libre inmediata, kmalloc retorna sin dormir y parece funcionar. Cuando el sistema esté bajo presión de memoria —justo cuando más importa— intentará dormir en contexto atómico y el sistema se colgará o entrará en pánico. Es el peor tipo de bug: funciona en pruebas y falla en producción bajo carga.

La alternativa correcta si hubiera que reservar en contexto atómico es GFP_ATOMIC, que nunca duerme pero puede fallar más a menudo y consume de una reserva de emergencia. Aun así, aquí la solución de diseño (workqueue) es mejor.

Con (f), escribir en un fichero:

Peor todavía. Escribir implica el sistema de archivos, la caché de páginas, el planificador de E/S de 02-05 y esperar al disco: milisegundos de bloqueo, con múltiples puntos donde el código duerme.

Consecuencias encadenadas:

Conclusión general del ejercicio: la división en dos mitades no existe para repartir trabajo, sino para minimizar la ventana en que el sistema no puede reaccionar al mundo exterior. Todo lo que no sea imprescindible hacer ahora mismo debe salir de la mitad superior.

Solución 3

1. Los dos puntos de pérdida.

Punto 1: en la tarjeta de red (hardware).

La tarjeta recibió los paquetes correctamente del cable pero no tenía dónde ponerlos: el anillo de 256 descriptores estaba lleno porque la softirq NET_RX no lo había vaciado a tiempo. Los paquetes se quedaron en el FIFO interno de la tarjeta hasta desbordarlo.

Estos paquetes nunca llegaron a la RAM. El núcleo no los vio jamás.

Punto 2: en la cola del backlog del núcleo.

La columna 2 es cero, así que no se descartaron en el backlog. Pero la columna 3 es la reveladora: 167.745 veces la softirq NET_RX agotó su presupuesto de tiempo o de paquetes y tuvo que ceder antes de vaciar el anillo.

Y ahí está la conexión causal entre ambos puntos: time_squeeze alto es la causa de rx_missed_errors. La softirq no puede seguir el ritmo, el anillo no se vacía, y la tarjeta pierde paquetes.

Además, la segunda línea de softnet_stat (CPU1) muestra 18.962 paquetes procesados frente a 16,9 millones de CPU0: todo el procesamiento está en un núcleo, el mismo problema del ejercicio 1.

Diferencia entre ambos puntos:

La cola del socket (ss) muestra Recv-Q: 0, así que el ingestor sí está leyendo a tiempo: no hay un tercer punto de pérdida. El problema es anterior a la aplicación.

2. Porcentaje de pérdida.

En lecturas diarias:

285.811 lecturas perdidas al día, irrecuperables. Puesto en contexto:

Un 0,41 % parece poco, pero para medias horarias por estación significa huecos sistemáticos en las series, y en el peor caso una estación concreta podría perder rachas enteras si su tráfico coincide con los momentos de desbordamiento.

3. Solución para cada punto de pérdida.

Para la pérdida en la tarjeta:

Por qué funciona cada una:

• (a) Da ocho veces más margen para absorber ráfagas. Con 2.048 descriptores a 800 paquetes/s, el sistema tiene 2,5 segundos de colchón en lugar de 0,3. Cuesta 4 MB de RAM.
• (b) Reparte el trabajo entre cuatro núcleos, atacando la causa raíz.
• (c) Reduce las interrupciones agrupando paquetes, dejando más CPU para el procesamiento real.

Para el time_squeeze:

• (d) netdev_budget es cuántos paquetes procesa la softirq antes de ceder. Subirlo de 300 a 600 reduce los time_squeeze a la mitad. El riesgo es que la softirq acapare más la CPU, así que conviene subirlo con moderación.
• (f) Reparte el procesamiento de la pila de red a CPU1-3 aunque la interrupción siga llegando a CPU0.

Hacerlo persistente:

4. El error de configuración en ps.

Las prioridades están invertidas. El agregador tiene prioridad elevada (−5) y el ingestor prioridad normal (0). Es exactamente lo contrario de lo que corresponde, y contradice lo que establecimos en 02-02:

Y esto agrava directamente el problema de pérdida. El razonamiento causal completo:

1. El agregador con nice −5 recibe ~75 % de la CPU en conflicto (tabla de pesos de 02-02).
2. Es un proceso limitado por CPU: cuando se ejecuta, retiene la CPU milisegundos enteros.
3. Las softirqs NET_RX compiten con él por CPU0.
4. Retrasar la softirq significa no vaciar el anillo → time_squeeze → rx_missed_errors.
5. El agregador mal priorizado está causando pérdida de lecturas.

La corrección:

Persistente en systemd:

Esto une las tres piezas del módulo: prioridad de CPU (02-02), afinidad de procesador (02-02) y afinidad de interrupciones (02-07), coordinadas para que el camino de las lecturas —tarjeta → softirq → socket → ingestor— no compita con el cálculo de medias en ningún punto.

5. Monitorización que lo habría detectado antes.

El fallo de proceso aquí es tan grave como el técnico: el problema lo detectó el equipo de datos al ver huecos, no el sistema. Para cuando alguien mira las series, ya se han perdido lecturas irrecuperables durante días.

Métricas y umbrales:

El criterio clave: para rx_missed_errors el umbral de aviso es cualquier incremento distinto de cero, porque cada unidad es una lectura perdida para siempre. No es una métrica de rendimiento, es una métrica de pérdida de datos.

Script de recogida:

Comprobación de extremo a extremo, la más valiosa:

Esta última es la que de verdad importa: mide el resultado, no los indicadores intermedios. Puede haber pérdidas en un punto que no estés vigilando —el switch, el cable, la propia estación—, y solo la comprobación de extremo a extremo las detecta todas.

Se comparan bien así:

Un sistema de monitorización decente tiene las tres: las de causa dan margen para actuar, las de síntoma localizan el punto exacto, y la de resultado garantiza que nada se escapa. Este planteamiento lo retomaremos en Monitorización y Diagnóstico de Rendimiento.

Un controlador de dispositivo es el software que traduce las operaciones genéricas del núcleo a las operaciones concretas de un modelo de hardware, y son el 63 % del código del núcleo de Linux. Cumplen un contrato —una estructura de punteros a función como file_operations— que implementa polimorfismo en C: la misma read() acaba en código distinto según el mayor del dispositivo. Se cargan como módulos cuyo alias conecta el identificador PCI del hardware con el nombre del módulo, lo que hace la carga automática. Y viven en anillo 0, sin red de seguridad: la traza Fatal exception in interrupt que hemos leído no termina en un SIGSEGV, termina en un kernel panic.

Una interrupción llega por una línea IRQ, se traduce en un vector y la CPU salta a la entrada correspondiente de la IDT, guardando estado y cambiando a la pila de núcleo igual que en una llamada al sistema. La diferencia decisiva es que una interrupción no pertenece a ningún proceso: se ejecuta sobre quien tocara, lo que prohíbe dormir, bloquearse, reservar memoria con GFP_KERNEL o tocar el espacio de usuario. De esa prohibición nace la división en mitad superior —microsegundos, reconocer el hardware y programar trabajo— y mitad inferior —softirq, tasklet o workqueue, con interrupciones habilitadas—. En el ejercicio hemos medido la diferencia: 1,1 µs frente a 54,1 µs de ceguera del sistema, un factor de 49.

NAPI resuelve el problema que dejamos planteado en la lección anterior: alterna entre interrupciones con carga baja y polling con carga alta, reduciendo 65 veces el coste a 500.000 paquetes/s. MSI-X elimina las líneas físicas, las carreras con el DMA y el límite de un vector por dispositivo, permitiendo una cola de interrupción por núcleo —que es lo que hace que nvme0q1 esté perfectamente repartido y enp3s0-rx-0 no—. El DMA trabaja con anillos de descriptores que dejan que la tarjeta escriba varios paquetes sin CPU, exige coordinar la coherencia de caché, y necesita la IOMMU para que un dispositivo comprometido no pueda escribir en cualquier dirección física. Y /proc/interrupts cuenta toda esta historia línea a línea: quién interrumpe, cuánto y en qué núcleo.

Con esto cierras el módulo 2, y merece la pena ver el recorrido completo. Empezaste abriendo la abstracción de proceso (02-01): su imagen de memoria, el task_struct, los estados con sus códigos reales, fork con copy-on-write, execve, los zombis y el coste del cambio de contexto. Después viste cómo se reparte la CPU entre ellos (02-02): ráfagas, criterios en conflicto, los algoritmos clásicos calculados a mano y el tiempo virtual justo de CFS con nice. Luego el segundo gran recurso, la memoria (02-03): direcciones lógicas y físicas, la MMU, la fragmentación con números y por qué la paginación gana; y su desarrollo completo (02-04): traducción, tablas multinivel, TLB, fallos de página, reemplazo, hiperpaginación, mmap y el OOM killer. Después el almacenamiento (02-05): la física del disco y del SSD, la planificación de peticiones y RAID. Y por último los dispositivos (02-06): la uniformización, /dev, udev y las tres formas de hablar con el hardware, que esta lección ha desarrollado hasta el final.

Las siete lecciones responden a la misma pregunta desde ángulos distintos: cómo se reparte un recurso escaso entre muchos que lo quieren. CPU, memoria, disco, dispositivos. Y en todas ha aparecido el mismo patrón: una abstracción que oculta la complejidad, un mecanismo de hardware que hace cumplir las reglas, y una política del sistema operativo que decide.

Pero hemos dado por supuesto algo grande. Cada vez que dos procesos compartían una página con MAP_SHARED, cada vez que una softirq y un proceso tocaban la misma cola, cada vez que dos trabajadores de meteo-api escribían en /dev/shm/meteora-cache, hemos dicho "esto requiere sincronización" y hemos seguido adelante. Ha llegado el momento de pagar esa deuda. ¿Qué ocurre exactamente cuando dos flujos de ejecución tocan el mismo dato a la vez? ¿Por qué contador++ puede perder incrementos? ¿Y cómo se coordinan sin destrozar el rendimiento que tanto ha costado conseguir?

Es el Módulo 3: Concurrencia, y empieza en Conceptos de Concurrencia.