Was kostet ein Context Switch tatsächlich und warum ist das wichtig?

Question

IT Interview Practice · Accepted Answer

Ein **Context Switch** ist, wenn der Kernel den CPU-Zustand des aktuell laufenden Threads speichert (Register, Program Counter, Stack Pointer) und den eines anderen Threads wiederherstellt, sodass ein einzelner Core viele Threads multiplexen kann. Er passiert bei jeder Scheduler-Preemption, jedem blockierenden Syscall oder Interrupt — und er ist nicht gratis.

## Wo die Kosten sich verstecken

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

Die **direkten** Kosten betragen wenige Mikrosekunden. Die **indirekten** Kosten — ein kalter Cache und TLB nach dem Switch — sind häufig der größere Schlag: der eingehende Thread läuft eine Weile langsam, während er seine Caches aus dem Hauptspeicher neu aufwärmt (Dutzende bis Hunderte Zyklen pro Miss).

## Thread- vs. Prozess-Switch

Das Wechseln zwischen **Threads desselben Prozesses** ist billiger: sie teilen sich einen Adressraum, sodass die Page Table (und der TLB, auf Hardware ohne getaggte TLBs / PCIDs) nicht wechseln muss. Das Wechseln von **Prozessen** lädt zusätzlich das Page-Table-Basisregister neu und flusht traditionell den TLB — weshalb es mehr kostet.

## Warum es in der Praxis wichtig ist

- **Zu viele Threads** → der Scheduler thrasht und verbringt Zyklen mit Wechseln statt mit Arbeit; ab einem Punkt *reduzieren* mehr Threads als Cores den Throughput.
- Es ist das Kernargument für **Async- / Event-Loop**-Modelle (Node, nginx, `io_uring`) und **Goroutines / Green Threads**: viele Verbindungen mit wenigen OS-Threads behandeln und einen Switch pro Request vermeiden.
- Es ist der Grund, warum **CPU-Pinning / Affinity** latenzsensiblen Diensten hilft — einen Thread auf einem Core halten, um seinen warmen Cache zu bewahren.
- Eine hohe Anzahl unfreiwilliger Context Switches (sichtbar in `vmstat`, `pidstat`) ist ein klassisches Symptom von Lock-Contention oder CPU-Übersubskription.

## Warum es wichtig ist

Dies ist eine Frage auf Senior-Niveau, weil sie Leute, die den *Begriff* kennen, von jenen trennt, die verstehen, *warum* er teuer ist — und die echte Antwort (Cache-/TLB-Verschmutzung, nicht nur Register-Speichern) treibt Architekturentscheidungen an: Async-I/O statt Thread-per-Request, Thread-Pools passend zur Core-Anzahl dimensionieren und Affinity nutzen. Es verbindet Scheduling, virtuellen Speicher und CPU-Caches zu einer einzigen Performance-Geschichte.

Wo die Kosten sich verstecken

Thread- vs. Prozess-Switch

Warum es in der Praxis wichtig ist

Warum es wichtig ist

Ähnliche Fragen