Resumen

  • El livelock de recepción aparece cuando las interrupciones de entrada consumen el tiempo que necesitan el protocolo, la salida o la aplicación; la CPU trabaja, pero ningún paquete completa el recorrido.
  • Mogul y Ramakrishnan combinaron interrupciones que despiertan un sondeo, servicio por turnos, cuotas, descarte temprano, realimentación desde colas posteriores y un límite de ciclos. Sondear sin cuota también fallaba.
  • Los resultados procedían de un DECstation monoprocesador lento y Ethernet de 10 Mbit/s. Cinco a diez paquetes por turno no eran una receta portátil.

La máquina trabajaba y el servicio desaparecía

Una interrupción permite que un evento físico adelante al trabajo ordinario. Con pocas llegadas reduce la espera. Bajo una inundación puede impedir que cualquier tarea de menor prioridad complete el paquete que la propia interrupción acaba de admitir.

En el diseño derivado de 4.2BSD estudiado por Mogul y Ramakrishnan, el controlador retiraba un paquete de la interfaz y lo colocaba en una cola IP. El procesamiento de protocolo ocurría después y a menor prioridad. Otra llegada podía interrumpirlo. Si la entrada no cedía, la cola se llenaba, los paquetes nuevos se descartaban después de consumir ciclos y ni la aplicación ni la interfaz de salida recibían trabajo útil.

No era un bloqueo irreversible: al bajar la carga, el sistema volvía a avanzar. Durante la sobrecarga, sin embargo, el contador correcto no era cuántas interrupciones habían sido atendidas. El rendimiento era lo entregado al consumidor final.

La prioridad era un planificador invisible

El planificador general casi no veía esas decisiones. La jerarquía fija de interrupciones había asignado autoridad absoluta a la recepción. Procesos de usuario, mantenimiento de rutas, protocolo y transmisión quedaban detrás.

Agrupar interrupciones disminuía el coste por paquete y retrasaba el colapso, pero no lo eliminaba. Acelerar la entrada no garantizaba que la salida obtuviera un turno.

La interrupción despierta; el sondeo reparte

El núcleo modificado conservó las interrupciones cuando el tráfico era ligero. Con carga alta, el manejador solo marcaba que había trabajo, programaba un hilo de sondeo y mantenía las interrupciones deshabilitadas.

El hilo visitaba en ronda las fuentes de recepción y transmisión. Cada llamada tenía una cuota. Cuando una interfaz ya no tenía trabajo pendiente, sus interrupciones volvían a habilitarse. Si el núcleo aceptaba un paquete, intentaba llevarlo hacia la salida en vez de dejarlo en otra frontera de prioridades.

Era un diseño híbrido. El sondeo puro desperdicia CPU y aumenta la latencia en silencio; la interrupción pura puede monopolizar la CPU en saturación. Una detectaba la llegada imprevisible y el otro administraba una corriente que ya era continua.

El fracaso sin cuota

La prueba más valiosa fue una derrota. Cuando la devolución de llamada de entrada no tenía cuota, siempre encontraba otro paquete y nunca regresaba al ciclo. El procesamiento de finalización de transmisión no se ejecutaba, la cola de salida se llenaba y el rendimiento volvía a acercarse a cero.

El mecanismo había cambiado de nombre, no de dueño. La cuota creó el turno de la salida. Entre cinco y diez paquetes dio un comportamiento estable en aquel equipo; los autores advirtieron que otra CPU o interfaz requeriría otro valor.

Descartar antes de invertir y escuchar la cola siguiente

Si la máquina no puede completar toda la oferta, conviene rechazar un paquete en la interfaz antes de gastar controlador, protocolo y memoria. La realimentación impide que la entrada siga celebrando admisiones que una etapa posterior ya no puede absorber.

Con screend, el núcleo detenía la entrada cuando la cola alcanzaba el 75 %, la retomaba al 25 % y usaba cerca de un milisegundo como temporizador de seguridad. Los umbrales eran arbitrarios. Lo importante era hacer visible la incapacidad aguas abajo.

Otro control medía los ciclos usados por la red en ventanas de diez milisegundos. Cuando agotaba su parte, la recepción cedía CPU a aplicaciones y tareas de mantenimiento. La interacción local mejoró, pero la remota seguía perdiendo paquetes. Una reserva no crea capacidad nueva.

Los recibos y su denominador

El equipo era un DECstation 3000/300 con Digital UNIX V3.2, elegido por ser el Alpha más lento disponible. Conectaba dos Ethernet de 10 Mbit/s. Cada ensayo enviaba 10.000 datagramas UDP con cuatro bytes de carga; la fuente no tenía ritmo perfecto y las tasas eran promedios.

En el núcleo original con screend, el deterioro empezó por encima de unos 2.000 paquetes por segundo y el livelock completo apareció cerca de 6.000. Sin screend, el máximo rondó 4.700. El informe dice expresamente que esos resultados no podían extrapolarse a redes y procesadores más rápidos. Tampoco demostraba SMP real ni resolvía qué clase de paquete debía sobrevivir.

La documentación actual de NAPI en Linux conserva una forma reconocible: una interrupción agenda un sondeo, las IRQ permanecen enmascaradas y un presupuesto limita cada ciclo. Es una comparación útil, no una licencia para llamar livelock a toda sobrecarga.

Google Research sitúa la carrera de Mogul en DEC/Compaq WRL, HP Labs y la infraestructura de red de Google. El artículo sigue siendo obra conjunta con Ramakrishnan. Su legado más exigente es el criterio de éxito: si la salida no avanza, el ruido de la entrada no cuenta como servicio.

Fuentes