Mibe kerül valójában egy context switch, és miért számít?

Question

IT Interview Practice · Accepted Answer

A **context switch** az, amikor a kernel elmenti az éppen futó thread CPU-állapotát (regiszterek, program counter, stack pointer), és visszaállít egy másik threadét, hogy egyetlen core sok threadet multiplexelhessen. Minden scheduler-preempciónál, blokkoló syscallnál vagy interruptnál megtörténik — és nem ingyenes.

## Hol rejtőzik a költség

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

A **közvetlen** költség néhány mikroszekundum. A **közvetett** költség — a hideg cache és TLB a switch után — gyakran a nagyobb ütés: a beérkező thread egy ideig lassan fut, ahogy újramelegíti a cache-eit a fő memóriából (miss-enként tíztől több száz ciklusig).

## Thread- vs process-váltás

A váltás **ugyanazon process threadjei** között olcsóbb: közös a címterük, így a page table (és a TLB, a tagged TLB / PCID nélküli hardveren) nem kell, hogy változzon. A **process-váltás** ezen felül újratölti a page-table bázisregisztert, és hagyományosan flusheli a TLB-t — ezért kerül többe.

## Miért számít a gyakorlatban

- **Túl sok thread** → a scheduler thrashel, ciklusokat váltásra költve munka helyett; egy ponton túl a core-oknál több thread *csökkenti* a throughputot.
- Ez a fő érv az **async / event-loop** modellek (Node, nginx, `io_uring`) és a **goroutine-ok / green threadek** mellett: sok kapcsolatot kevés OS-threaddel kezelni, elkerülve a kérésenkénti váltást.
- Ezért segít a **CPU pinning / affinity** a latency-érzékeny szolgáltatásoknak — tartsd egy threadet egy core-on, hogy megőrizd a meleg cache-ét.
- A magas akaratlan (involuntary) context-switch-szám (látható a `vmstat`, `pidstat` alatt) a lock contention vagy a CPU-túlterhelés (oversubscription) klasszikus tünete.

## Miért fontos

Ez egy senior szintű kérdés, mert elválasztja azokat, akik ismerik a *fogalmat*, azoktól, akik értik, *miért* drága — és a valódi válasz (cache/TLB-szennyezés, nem csak a regiszterek mentése) architekturális döntéseket vezérel: async I/O a thread-per-request helyett, a thread pool-ok méretezése a core-számhoz, és az affinity használata. A schedulingot, a virtuális memóriát és a CPU-cache-eket egyetlen teljesítménytörténetbe köti.

Hol rejtőzik a költség

Thread- vs process-váltás

Miért számít a gyakorlatban

Miért fontos

Kapcsolódó kérdések