Во что реально обходится context switch, и почему это важно?

Question

IT Interview Practice · Accepted Answer

**Context switch** (переключение контекста) — это сохранение ядром состояния CPU текущего потока (регистры, счётчик команд, указатель стека) и восстановление состояния другого потока, чтобы одно ядро могло мультиплексировать множество потоков. Он происходит при каждом вытеснении планировщиком, блокирующем syscall или прерывании — и он не бесплатен.

## Где прячется стоимость

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

**Прямая** стоимость — несколько микросекунд. **Косвенная** стоимость — холодный cache и TLB после переключения — часто оказывается бо́льшим ударом: входящий поток какое-то время работает медленно, пока заново прогревает свои кэши из основной памяти (десятки-сотни циклов на промах).

## Переключение потока vs процесса

Переключение между **потоками одного процесса** дешевле: они разделяют адресное пространство, поэтому page table (и TLB на железе без tagged TLB / PCID) менять не нужно. Переключение **процессов** дополнительно перезагружает базовый регистр page-table и традиционно сбрасывает (flush) TLB — поэтому оно стоит дороже.

## Почему это важно на практике

- **Слишком много потоков** → планировщик буксует (thrash), тратя циклы на переключения, а не на работу; за некоторым порогом бо́льшее число потоков, чем ядер, *снижает* throughput.
- Это ключевой аргумент в пользу моделей **async / event-loop** (Node, nginx, `io_uring`) и **goroutines / green threads**: обслуживать множество соединений немногими OS-потоками, избегая переключения на каждый запрос.
- Поэтому **CPU pinning / affinity** помогает сервисам, чувствительным к задержке — держать поток на одном ядре, чтобы сохранить его тёплый cache.
- Высокое число непроизвольных (involuntary) переключений контекста (видно в `vmstat`, `pidstat`) — классический симптом конкуренции за блокировки или переподписки CPU.

## Почему это важно

Это вопрос уровня senior, потому что он отделяет тех, кто знает *термин*, от тех, кто понимает, *почему* это дорого — и настоящий ответ (загрязнение cache/TLB, а не только сохранение регистров) определяет архитектурные решения: async I/O вместо thread-per-request, правильный размер пулов потоков под число ядер, использование affinity. Он связывает планирование, виртуальную память и кэши CPU в единую историю о производительности.

Где прячется стоимость

Переключение потока vs процесса

Почему это важно на практике

Почему это важно

Похожие вопросы