¿Qué cuesta realmente un context switch, y por qué importa?

Question

IT Interview Practice · Accepted Answer

Un **context switch** es cuando el kernel guarda el estado de CPU del thread en ejecución (registros, program counter, stack pointer) y restaura el de otro thread, de modo que un solo core pueda multiplexar muchos threads. Ocurre en cada preemption del scheduler, cada syscall bloqueante, o cada interrupt — y no es gratis.

## Dónde se esconde el coste

```text
DIRECT cost (visible, ~1–5 µs):
  save/restore registers · run scheduler logic · switch kernel stacks
  if PROCESS switch: also swap page tables (CR3) → FLUSHES the TLB

INDIRECT cost (often much larger):
  cold CPU CACHES → the new thread's data isn't in L1/L2/L3 → cache misses to RAM
  cold TLB        → address translations must be re-walked
  lost pipeline / branch-predictor state
```

El coste **directo** es de unos pocos microsegundos. El coste **indirecto** — una cache y una TLB frías tras el cambio — es a menudo el golpe mayor: el thread entrante corre lento durante un rato mientras recalienta sus caches desde la memoria principal (decenas a cientos de ciclos por miss).

## Cambio de thread vs de proceso

Cambiar entre **threads del mismo proceso** es más barato: comparten un address space, así que la page table (y la TLB, en hardware sin tagged TLBs / PCIDs) no necesita cambiar. Cambiar de **proceso** además recarga el registro base de la page table y tradicionalmente hace flush de la TLB — por eso cuesta más.

## Por qué importa en la práctica

- **Demasiados threads** → el scheduler entra en thrashing, gastando ciclos en cambiar en lugar de trabajar; pasado un punto, más threads que cores *reduce* el throughput.
- Es el argumento central para los modelos **async / event-loop** (Node, nginx, `io_uring`) y las **goroutines / green threads**: manejar muchas conexiones con pocos OS threads, evitando un cambio por request.
- Es por lo que el **CPU pinning / affinity** ayuda a los servicios sensibles a la latencia — mantener un thread en un core para preservar su cache caliente.
- Un número alto de context-switches involuntarios (visible en `vmstat`, `pidstat`) es un síntoma clásico de lock contention o de sobresuscripción (oversubscription) de CPU.

## Por qué es importante

Esta es una pregunta de nivel senior porque separa a quienes conocen el *término* de quienes entienden *por qué* es caro — y la respuesta real (la contaminación de cache/TLB, no solo el guardado de registros) guía decisiones de arquitectura: async I/O en vez de thread-per-request, dimensionar los thread pools al número de cores, y usar affinity. Une el scheduling, la memoria virtual y las caches de CPU en una sola historia de rendimiento.

Dónde se esconde el coste

Cambio de thread vs de proceso

Por qué importa en la práctica

Por qué es importante

Preguntas relacionadas