Vad kostar en context switch egentligen, och varför spelar det roll?

Question

IT Interview Practice · Accepted Answer

En **context switch** är kernel som sparar den nu körande threadens CPU-tillstånd (register, program counter, stack pointer) och återställer en annan threads, så att en enda core kan multiplexa många threads. Det sker vid varje scheduler-preemption, blockerande syscall, eller interrupt — och det är inte gratis.

## Var kostnaden gömmer sig

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

Den **direkta** kostnaden är några mikrosekunder. Den **indirekta** kostnaden — en kall cache och TLB efter switchen — är ofta den större smällen: den inkommande threaden körs långsamt ett tag medan den värmer upp sina cachar från huvudminnet igen (tiotals till hundratals cykler per miss).

## Thread- vs process-switch

Att växla mellan **threads i samma process** är billigare: de delar ett adressutrymme, så page table (och TLB:n, på hårdvara utan tagged TLBs / PCIDs) behöver inte ändras. Att växla **processer** laddar dessutom om page-table-basregistret och flushar traditionellt TLB:n — vilket är varför det kostar mer.

## Varför det spelar roll i praktiken

- **För många threads** → schedulern thrashar och spenderar cykler på att växla i stället för att arbeta; bortom en viss punkt *minskar* fler threads än cores throughput.
- Det är kärnargumentet för **async / event-loop**-modeller (Node, nginx, `io_uring`) och **goroutines / green threads**: hantera många anslutningar med få OS-threads och undvik en switch per request.
- Det är varför **CPU pinning / affinity** hjälper latency-känsliga tjänster — håll en thread på en core för att bevara dess varma cache.
- Ett högt antal ofrivilliga (involuntary) context switches (synligt i `vmstat`, `pidstat`) är ett klassiskt symptom på lock contention eller CPU-överbokning.

## Varför det är viktigt

Detta är en fråga på seniornivå eftersom den skiljer dem som kan *termen* från dem som förstår *varför* den är dyr — och det verkliga svaret (cache-/TLB-förorening, inte bara registerlagringar) driver arkitekturbeslut: async I/O framför thread-per-request, rätt dimensionering av thread pools efter antalet cores, och användning av affinity. Det knyter ihop scheduling, virtuellt minne och CPU-cachar till en enda prestandaberättelse.

Var kostnaden gömmer sig

Thread- vs process-switch

Varför det spelar roll i praktiken

Varför det är viktigt

Relaterade frågor