Que coûte réellement un context switch, et pourquoi est-ce important ?

Question

IT Interview Practice · Accepted Answer

Un **context switch (changement de contexte)** est l'action du kernel de sauvegarder l'état CPU du thread en cours d'exécution (registres, program counter, stack pointer) et de restaurer celui d'un autre thread, afin qu'un seul cœur puisse multiplexer de nombreux threads. Il se produit à chaque préemption du scheduler, à chaque syscall bloquant, ou à chaque interruption — et ce n'est pas gratuit.

## Où se cache le coût

```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
```

Le coût **direct** est de quelques microsecondes. Le coût **indirect** — un cache et un TLB froids après le changement — est fréquemment le plus gros impact : le thread entrant s'exécute lentement pendant un moment le temps de réchauffer ses caches depuis la mémoire principale (des dizaines à des centaines de cycles par miss).

## Changement de thread vs de process

Passer **entre threads d'un même processus** est moins coûteux : ils partagent un espace d'adressage, donc la page table (et le TLB, sur du matériel sans tagged TLBs / PCIDs) n'a pas besoin de changer. Changer de **processus** recharge en plus le registre de base de la page table et, traditionnellement, vide (flush) le TLB — c'est pourquoi cela coûte plus cher.

## Pourquoi c'est important en pratique

- **Trop de threads** → le scheduler s'emballe (thrash), dépensant des cycles à changer plutôt qu'à travailler ; au-delà d'un certain point, plus de threads que de cœurs *réduit* le throughput.
- C'est l'argument central en faveur des modèles **async / event-loop** (Node, nginx, `io_uring`) et des **goroutines / green threads** : gérer de nombreuses connexions avec peu de threads OS, en évitant un changement par requête.
- C'est pourquoi le **CPU pinning / affinity** aide les services sensibles à la latence — garder un thread sur un cœur pour préserver son cache chaud.
- Un nombre élevé de context switches involontaires (visible dans `vmstat`, `pidstat`) est un symptôme classique de contention de locks ou de sur-souscription (oversubscription) du CPU.

## Pourquoi c'est important

C'est une question de niveau senior car elle sépare ceux qui connaissent le *terme* de ceux qui comprennent *pourquoi* c'est coûteux — et la vraie réponse (pollution du cache/TLB, pas seulement la sauvegarde des registres) guide les décisions architecturales : async I/O plutôt que thread-per-request, dimensionnement des thread pools au nombre de cœurs, et usage de l'affinity. Elle relie l'ordonnancement, la mémoire virtuelle et les caches CPU en une seule histoire de performance.

Où se cache le coût

Changement de thread vs de process

Pourquoi c'est important en pratique

Pourquoi c'est important

Questions connexes