Cât costă de fapt un context switch și de ce contează?

Question

IT Interview Practice · Accepted Answer

Un **context switch** este momentul în care kernel-ul salvează starea CPU a thread-ului aflat în execuție (regiștri, program counter, stack pointer) și o restaurează pe a altui thread, astfel încât un singur core să poată multiplexa multe thread-uri. Se întâmplă la fiecare preempțiune a scheduler-ului, syscall blocant sau întrerupere — și nu e gratuit.

## Unde se ascunde costul

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

Costul **direct** este de câteva microsecunde. Costul **indirect** — un cache și un TLB reci după switch — este frecvent lovitura mai mare: thread-ul care intră rulează lent o vreme, pe măsură ce își reîncălzește cache-urile din memoria principală (zeci până la sute de cicluri per miss).

## Switch de thread vs de proces

Trecerea între **thread-uri ale aceluiași proces** este mai ieftină: împart un spațiu de adrese, așa că page table-ul (și TLB-ul, pe hardware fără tagged TLB / PCID) nu trebuie să se schimbe. Trecerea între **procese** reîncarcă în plus registrul de bază al page table-ului și, tradițional, golește TLB-ul — de aceea costă mai mult.

## De ce contează în practică

- **Prea multe thread-uri** → scheduler-ul face thrashing, cheltuind cicluri comutând în loc să lucreze; peste un punct, mai multe thread-uri decât core-uri *reduc* throughput-ul.
- Este argumentul de bază pentru modelele **async / event-loop** (Node, nginx, `io_uring`) și **goroutine / green thread**: gestionează multe conexiuni cu puține thread-uri de OS, evitând un switch per cerere.
- De aceea **CPU pinning / affinity** ajută serviciile sensibile la latență — ține un thread pe un core pentru a-i păstra cache-ul cald.
- Un număr mare de context switch-uri involuntare (vizibil în `vmstat`, `pidstat`) este un simptom clasic de lock contention sau supra-abonare a CPU.

## De ce contează

Aceasta este o întrebare de nivel senior pentru că separă oamenii care cunosc *termenul* de cei care înțeleg *de ce* este scump — iar răspunsul real (poluarea cache/TLB, nu doar salvarea regiștrilor) determină decizii arhitecturale: async I/O în locul thread-per-request, dimensionarea corectă a thread pool-urilor după numărul de core-uri și folosirea affinity. Leagă scheduling-ul, memoria virtuală și cache-urile CPU într-o singură poveste de performanță.

Unde se ascunde costul

Switch de thread vs de proces

De ce contează în practică

De ce contează

Întrebări conexe