Ile faktycznie kosztuje przełączenie kontekstu i dlaczego ma to znaczenie?

Question

IT Interview Practice · Accepted Answer

**Przełączenie kontekstu (context switch)** to zapisanie przez kernel stanu CPU aktualnie działającego wątku (rejestry, licznik rozkazów, wskaźnik stosu) i przywrócenie stanu innego wątku, tak by pojedynczy rdzeń mógł multipleksować wiele wątków. Zdarza się przy każdej preempcji schedulera, blokującym syscallu lub przerwaniu — i nie jest darmowe.

## Gdzie kryje się koszt

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

Koszt **bezpośredni** to kilka mikrosekund. Koszt **pośredni** — zimny cache i TLB po przełączeniu — jest często większym ciosem: wchodzący wątek działa przez chwilę wolno, gdy na nowo rozgrzewa swoje cache'e z pamięci głównej (dziesiątki do setek cykli na chybienie).

## Przełączenie wątku a procesu

Przełączanie między **wątkami tego samego procesu** jest tańsze: współdzielą przestrzeń adresową, więc page table (i TLB, na sprzęcie bez tagowanych TLB / PCID) nie musi się zmieniać. Przełączanie **procesów** dodatkowo przeładowuje rejestr bazowy page table i tradycyjnie czyści (flush) TLB — dlatego kosztuje więcej.

## Dlaczego ma to znaczenie w praktyce

- **Zbyt wiele wątków** → scheduler się miota, spędzając cykle na przełączaniu zamiast na pracy; powyżej pewnego punktu więcej wątków niż rdzeni *zmniejsza* przepustowość.
- To główny argument za modelami **async / event-loop** (Node, nginx, `io_uring`) i **goroutine / green threads**: obsłuż wiele połączeń kilkoma wątkami OS, unikając przełączenia na każde żądanie.
- To dlatego **przypinanie CPU / affinity** pomaga usługom wrażliwym na opóźnienia — trzymaj wątek na jednym rdzeniu, by zachować jego rozgrzany cache.
- Wysoka liczba niedobrowolnych (involuntary) przełączeń kontekstu (widoczna w `vmstat`, `pidstat`) to klasyczny objaw rywalizacji o locki lub przeciążenia CPU (oversubscription).

## Dlaczego to ważne

To pytanie na poziomie senior, bo oddziela ludzi, którzy znają *termin*, od tych, którzy rozumieją, *dlaczego* jest kosztowny — a prawdziwa odpowiedź (zanieczyszczenie cache/TLB, nie tylko zapisy rejestrów) napędza decyzje architektoniczne: async I/O zamiast wątku na żądanie, dobranie rozmiaru pul wątków do liczby rdzeni i użycie affinity. Spina planowanie, pamięć wirtualną i cache'e CPU w jedną historię o wydajności.

Gdzie kryje się koszt

Przełączenie wątku a procesu

Dlaczego ma to znaczenie w praktyce

Dlaczego to ważne

Powiązane pytania