Top half y bottom half: el arte de diferir

Un manejador de interrupción no es un lugar donde trabajar: es un lugar del que huir cuanto antes. Mientras corre, la línea que lo disparó está enmascarada y, en muchos casos, otras interrupciones esperan detrás de él. Cada instrucción que ejecutas dentro es latencia que le robas al reloj del sistema, al siguiente paquete, al temporizador que debía disparar. La solución que el kernel adoptó hace décadas y sigue perfeccionando es partir el trabajo en dos: una mitad superior brevísima que hace lo imprescindible ahora, y una mitad inferior que hace lo pesado después, con las puertas ya reabiertas.

El coste oculto de un manejador lento

Mientras tu manejador dura ejecuta, la CPU está en contexto de interrupción con esa línea enmascarada. Si el manejador tarda cincuenta microsegundos copiando un buffer o esperando a un chip lento, durante esos cincuenta microsegundos ese dispositivo no puede volver a avisar, el temporizador de alta resolución acumula retraso, y otro dispositivo que comparta la línea o la prioridad espera su turno. La latencia de interrupción —el tiempo desde que el hardware la eleva hasta que se atiende de verdad— es una métrica de calidad de todo el sistema, y el peor manejador de cualquier driver cargado fija su límite inferior.

/* ANTIPATRÓN: un manejador que hace el trabajo entero dentro */
static irqreturn_t mal_handler(int irq, void *dev_id)
{
	struct mi_nic *nic = dev_id;
	int i;

	for (i = 0; i < nic->rx_pendientes; i++) {
		struct sk_buff *skb = construir_skb(nic, i); /* asigna, copia... */
		netif_rx(skb);                               /* procesa la pila entera */
	}
	return IRQ_HANDLED;   /* y mientras tanto NADIE más ha podido interrumpir */
}

Ese bucle puede recorrer cientos de paquetes con las interrupciones cerradas. Es correcto y es un desastre: convierte una ráfaga de red en una pausa ciega para el resto de la máquina.

Partir en dos: reconocer arriba, procesar abajo

La disciplina es milenaria en la escala del kernel: la mitad superior (top half) es el manejador dura y hace solo lo que no admite espera —reconocer la interrupción en el hardware, rescatar el dato que se perdería si tardas, apuntar qué queda por hacer y programar la mitad inferior—. La mitad inferior (bottom half) corre después, con las interrupciones ya reabiertas, y hace el trabajo caro. El término “bottom half” nació con un mecanismo concreto de los años noventa; hoy es genérico y designa a cualquiera de sus herederos.

/* PATRÓN: la mitad superior hace lo mínimo y difiere el resto */
static irqreturn_t buen_handler(int irq, void *dev_id)
{
	struct mi_nic *nic = dev_id;
	u32 status = readl(nic->regs + REG_INT_STATUS);

	if (!(status & INT_RX))
		return IRQ_NONE;

	/* 1. reconocer y enmascarar en el dispositivo: no vuelvas a interrumpir */
	writel(INT_RX, nic->regs + REG_INT_MASK_SET);
	/* 2. programar la mitad inferior; ella drenará los paquetes con calma */
	napi_schedule(&nic->napi);

	return IRQ_HANDLED;   /* salgo en nanosegundos, no en microsegundos */
}

Fíjate en el gesto clave: la mitad superior enmascara su propia fuente antes de irse. Así, mientras la mitad inferior drena el anillo de recepción, el dispositivo no vuelve a interrumpir por cada paquete; una sola interrupción paga el procesamiento de muchos. Es el corazón de NAPI, el modelo de recepción de red del kernel, y el ejemplo canónico de por qué diferir no solo mejora la latencia sino también el rendimiento bruto.

flowchart LR
HW[Dispositivo eleva IRQ] --> TH[Mitad superior]
subgraph Contexto de interrupcion atomico
  TH --> A1[Reconoce y enmascara el hardware]
  A1 --> A2[Rescata lo urgente]
  A2 --> A3[Programa la mitad inferior]
end
A3 --> BH[Mitad inferior]
subgraph Interrupciones ya reabiertas
  BH --> B1[Procesa el lote entero]
  B1 --> B2[Despierta a quien esperaba]
end
style TH fill:#f38ba8,color:#11111b
style BH fill:#a6e3a1,color:#11111b

El abanico de mitades inferiores

“Diferir” no es un único mecanismo sino una familia, y su eje de decisión es una sola pregunta: ¿el trabajo diferido necesita dormir? Si no puede dormir pero debe correr cuanto antes, vive en contexto atómico (softirq, tasklet). Si puede y quiere dormir —tomar un mutex, hablar por un bus lento, asignar con GFP_KERNEL— necesita contexto de proceso (hilo de IRQ, workqueue).

Cada uno de los cuatro compra una libertad a cambio de latencia. El softirq apenas cuesta un retorno de interrupción pero no puede dormir; el workqueue puede hacer cualquier cosa pero paga un cambio de contexto. Elegir bien es situar cada trabajo en el punto justo de ese compromiso, y los tres niveles siguientes los recorren uno a uno.

Cuándo un manejador puede hacerlo todo

No toda interrupción necesita mitad inferior. Si el manejador solo tiene que leer un registro, apuntar un valor y despertar a un durmiente, eso cabe entero en la mitad superior y partir sería un coste sin premio. El criterio es cuantitativo: si tu manejador termina en un puñado de instrucciones y jamás toca nada que pueda bloquear, déjalo entero. En cuanto aparezca un bucle no acotado, una asignación grande, una espera por hardware o una copia a usuario, esa parte se va abajo. La pregunta no es “¿debo dividir?” sino “¿cuánto de esto no admite estar en contexto de interrupción?”.

/* mitad superior autosuficiente: nada aquí puede bloquear, no hay mitad inferior */
static irqreturn_t boton_handler(int irq, void *dev_id)
{
	struct boton *b = dev_id;
	u32 estado = readl(b->regs + REG_GPIO);    /* lectura MMIO: no duerme */

	writel(estado, b->regs + REG_GPIO_ACK);    /* reconocer la fuente */
	input_report_key(b->input, KEY_POWER, !!(estado & PIN_BOTON));
	input_sync(b->input);                      /* despierta a los lectores sin dormir */
	return IRQ_HANDLED;
}

Un botón GPIO es el caso puro: leer el pin, reconocer, notificar y salir son cuatro accesos que jamás bloquean. Meterle una mitad inferior sería añadir un cambio de contexto para no ganar nada. El arte de este nivel no es diferir siempre, sino diferir solo lo que no cabe en el instante atómico.