Quanto realmente custa um context switch, e por que isso importa?

Question

IT Interview Practice · Accepted Answer

Um **context switch** é o kernel salvando o estado de CPU da thread em execução (registradores, program counter, stack pointer) e restaurando o de outra thread, para que um único core possa multiplexar muitas threads. Acontece a cada preempção do scheduler, syscall bloqueante, ou interrupt — e não é de graça.

## Onde o custo se esconde

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

O custo **direto** é de alguns microssegundos. O custo **indireto** — uma cache e TLB frias depois do switch — frequentemente é o golpe maior: a thread que entra roda devagar por um tempo enquanto reaquece suas caches a partir da memória principal (dezenas a centenas de cycles por miss).

## Switch de thread vs de processo

Alternar entre **threads do mesmo processo** é mais barato: elas compartilham um address space, então a page table (e a TLB, em hardware sem tagged TLBs / PCIDs) não precisa mudar. Alternar entre **processos** adicionalmente recarrega o registrador base da page table e tradicionalmente dá flush na TLB — e é por isso que custa mais.

## Por que importa na prática

- **Threads demais** → o scheduler entra em thrash, gastando cycles alternando em vez de trabalhando; passado um certo ponto, mais threads do que cores *reduz* o throughput.
- É o argumento central para os modelos **async / event-loop** (Node, nginx, `io_uring`) e **goroutines / green threads**: atender muitas conexões com poucas OS threads, evitando um switch por request.
- É por isso que **CPU pinning / affinity** ajuda serviços sensíveis à latência — manter uma thread em um core para preservar sua cache quente.
- Uma contagem alta de context-switches involuntários (visível em `vmstat`, `pidstat`) é um sintoma clássico de lock contention ou de oversubscription de CPU.

## Por que isso importa

Esta é uma pergunta de nível senior porque separa quem conhece o *termo* de quem entende *por que* ele é caro — e a resposta real (poluição da cache/TLB, não apenas o salvamento de registradores) orienta decisões de arquitetura: async I/O em vez de thread-per-request, dimensionar os thread pools de acordo com a quantidade de cores, e usar affinity. Ela amarra scheduling, memória virtual, e caches de CPU em uma única história de desempenho.

Onde o custo se esconde

Switch de thread vs de processo

Por que importa na prática

Por que isso importa

Perguntas relacionadas