Restartable Sequences en Linux: guía clara

Si alguna vez mediste un servicio concurrente en Linux y viste que el cuello de botella no era la red ni la base de datos, sino la coordinación entre hilos, ya sabes dónde duele. A veces el problema no está en la lógica de negocio, sino en una operación pequeña que se repite millones de veces: tomar un lock, buscar una estructura, actualizar un contador, soltar el lock. Cuando eso pasa en caliente, cualquier microsegundo importa.

Ahí entra Restartable Sequences, o rseq. No es una API para hacer magia ni un reemplazo universal de los locks. Es una pieza del kernel pensada para reducir contención en secciones muy cortas de código, donde un hilo puede ejecutar una secuencia de instrucciones localmente y, si el kernel lo interrumpe en el momento equivocado, reiniciarla de forma segura. En otras palabras: menos coordinación global para ciertas operaciones de bajo nivel.

Qué problema resuelve rseq

Cuando tienes varios hilos compitiendo por la misma estructura de datos, el costo no siempre viene del trabajo útil. Muchas veces viene de la espera: cache lines que rebotan entre CPUs, atomics que fallan por contención, spinlocks que se recalientan y convoyes de bloqueo que se comen la latencia. Si tu carga hace millones de operaciones pequeñas, ese costo se acumula rápido.

La idea de rseq es permitir que algunas operaciones se ejecuten de forma casi local a cada CPU. En vez de tratar de coordinar todo con atomics globales, el código puede trabajar con datos que dependen del CPU actual y confiar en que, si ocurre una interrupción, migración de CPU o evento que invalide la secuencia, el kernel haga rollback lógico y el proceso reintente. Eso reduce la necesidad de sincronización pesada en caminos críticos.

El caso típico: contadores y estructuras por CPU

Un ejemplo clásico es un contador por CPU. Si cada incremento necesitara un atomic global, cada hilo pelearía por la misma línea de caché. Con una estrategia por CPU, cada hilo actualiza una copia local y luego agregas al final. rseq ayuda a que esa actualización local sea segura incluso si el hilo cambia de CPU en medio de la operación.

La documentación del kernel explica el mecanismo y sus restricciones con bastante claridad: la secuencia debe ser corta, no debe bloquear y debe asumir que puede ser interrumpida. Si quieres leer la base oficial, empieza por la documentación del kernel Linux sobre rseq: https://docs.kernel.org/userspace-api/rseq.html y la página de manual de la syscall: https://man7.org/linux/man-pages/man2/rseq.2.html.

Qué no hace

rseq no reemplaza mutexes, no sirve para secciones largas y no te evita pensar en consistencia. Tampoco convierte cualquier código concurrente en código rápido por arte de registro. Lo que hace es dar una herramienta para un tipo muy específico de trabajo: operaciones cortas, frecuentes, sensibles a contención y con estado localizable por CPU.

Cómo funciona por dentro

La pieza central es una secuencia registrada en userspace. El proceso le dice al kernel dónde empieza y dónde termina una región crítica muy corta. Si el hilo entra en esa región y algo rompe la suposición de ejecución continua, el kernel puede abortar la secuencia y llevar el control a una ruta de fallback.

Eso suena abstracto hasta que lo piensas con una analogía concreta: imagina que estás llenando sobres en una mesa asignada a una sola persona. Si nadie te mueve de esa mesa, todo va bien. Si te cambian de mesa a mitad de llenar un sobre, no quieres dejar el proceso en un estado raro. rseq permite detectar esa interrupción y reiniciar de forma controlada.

Registro, abort y retry

El flujo general es este:

1. El hilo registra su área rseq con el kernel.
2. Entra a una secuencia corta que asume ejecución local.
3. Si no hay interrupción, termina y deja el estado consistente.
4. Si el kernel detecta una condición que invalida la secuencia, salta a una ruta de abort.
5. El código decide si reintenta, cae a un camino lento o usa un mecanismo alterno.

Ese patrón es útil porque separa el camino rápido del camino seguro. El camino rápido evita contención global. El camino lento absorbe los casos raros.

Restricciones que sí importan

No puedes meter cualquier cosa dentro de una restartable sequence. Debe ser corto, predecible y con muy pocas instrucciones. Si metes llamadas al sistema, locks, I/O o lógica compleja, pierdes el beneficio y te acercas a un diseño frágil.

Además, rseq depende de soporte del kernel y de que tu aplicación lo use de forma correcta. En kernels modernos y distribuciones recientes suele estar disponible, pero si construyes software que corre en ambientes heterogéneos, conviene verificarlo en runtime y tener fallback. En producción eso no es opcional.

Dónde sí se nota el rendimiento

El mayor valor aparece cuando tienes muchas operaciones pequeñas que compiten por recursos compartidos. No hablamos de un 2% bonito para una slide, sino de evitar que una línea de caché se convierta en punto de pelea constante. En sistemas con alta concurrencia, eso puede traducirse en menos latencia p99 y más throughput estable.

Un área donde esto se usa o se discute mucho es en allocators y contadores por CPU. Si cada thread puede actualizar estructuras locales sin tomar un lock global, reduces el tráfico de coherencia entre CPUs. Eso suele ser más valioso que intentar optimizar una sola instrucción.

Ejemplos reales de uso

Algunas implementaciones de allocators y runtimes usan ideas cercanas a rseq para mejorar el manejo de memoria por CPU. El objetivo no es solo velocidad bruta, sino evitar que el rendimiento se degrade cuando sube el número de hilos. En cargas con 8, 16 o 32 cores, ese detalle cambia bastante el perfil.

También es útil en contadores, estadísticas y colas donde el acceso local domina. Si tu servicio registra métricas por request y cada request toca una estructura compartida, puedes terminar pagando más por sincronización que por el trabajo de negocio. Ahí un diseño por CPU o por shard, combinado con rseq, puede bajar bastante la presión sobre el sistema.

Cuándo no vale la pena

Si tu aplicación hace poca concurrencia, o si la sección crítica ya es larga por naturaleza, rseq probablemente no te aporte mucho. Tampoco compensa si tu cuello de botella está en red, disco o serialización JSON. En esos casos conviene arreglar el problema grande antes de mirar una optimización de bajo nivel.

Cómo se usa en código de bajo nivel

No necesitas escribir kernel code para aprovechar la idea, pero sí conviene entender la forma mental. El patrón es: intenta el camino local rápido, valida que sigues en el contexto esperado y, si no, cae a un fallback seguro. Eso obliga a diseñar el código con dos rutas, no una sola.

En C o C++ normalmente verás esta lógica muy cerca de estructuras por CPU, contadores y allocators. En runtimes más complejos, la implementación suele esconderse detrás de abstracciones internas. Tú no siempre llamas rseq directamente, pero sí puedes beneficiarte de librerías que ya lo integran.

// Pseudocódigo conceptual, no es una implementación completa
int try_fast_path(struct cpu_local *local) {
  int cpu = read_current_cpu();
  if (cpu != local->expected_cpu) {
    return -1; // fallback
  }

  local->counter += 1;
  return 0;
}

Ese ejemplo es intencionalmente simple. En la práctica, rseq se apoya en soporte del kernel y en una secuencia más controlada que evita estados intermedios inconsistentes. La idea útil para ti no es copiar este snippet, sino entender el patrón: minimizar coordinación y hacer que el fallback absorba la rareza.

Checklist práctico antes de adoptarlo

1. Mide primero el problema con perf, eBPF o flamegraphs.
2. Confirma que el cuello de botella es contención, no I/O.
3. Identifica si la operación puede ser local por CPU o por shard.
4. Diseña una ruta rápida corta y un fallback correcto.
5. Verifica soporte de kernel y comportamiento en producción.
6. Prueba con cargas de 1, 4, 8, 16 y 32 hilos para ver si escala.

Si no puedes responder sí a la mayoría, probablemente no necesitas rseq todavía. Y eso también está bien. Optimizar bajo nivel sin medir suele ser una forma elegante de perder tiempo.

Qué debes revisar antes de implementarlo

Primero, tu modelo de datos. rseq funciona mejor cuando el estado que actualizas puede dividirse por CPU, por thread o por shard. Si todo depende de un único objeto global, vas a pelear contra la física del hardware, no contra una mala API.

Segundo, tu tolerancia al fallback. Una restartable sequence no garantiza que siempre completes el camino rápido. Por diseño, puede abortar. Por eso necesitas que la ruta lenta sea correcta y suficientemente barata para no arruinar el promedio.

Tercero, tu portabilidad. Si tu software vive en servidores administrados por terceros, contenedores o distros viejas, no asumas soporte uniforme. Documenta el requisito, detecta el feature y mide el impacto real en cada entorno.

Señales de que sí encaja

• Tienes muchos hilos y alta frecuencia de actualización.
• La contención aparece en perfiles de CPU.
• El trabajo por operación es pequeño, del orden de nanosegundos o pocos microsegundos.
• Puedes reorganizar datos para que sean locales al CPU.
• Ya agotaste optimizaciones más obvias como batching o sharding.

Señales de que no encaja

• La mayor parte del tiempo se va en red o disco.
• La sección crítica hace trabajo pesado o llamadas externas.
• El servicio tiene poca concurrencia real.
• No puedes ofrecer un fallback correcto.
• Tu equipo no puede mantener código de bajo nivel con pruebas serias.

Tabla resumen

Si te quedas con una sola idea, que sea esta: rseq no es una optimización genérica, es una herramienta especializada para quitar fricción donde los locks y atomics empiezan a doler. En sistemas bien afinados, ese tipo de detalle se nota más de lo que parece. En sistemas mal medidos, solo añade complejidad.

Antes de tocarlo, mira el perfil, identifica la contención y confirma que el estado puede vivir cerca del CPU. Si eso cuadra, restartable sequences puede ser una pieza muy útil de tu caja de herramientas. Si no, probablemente hay una optimización más simple esperando primero.