What does a context switch actually cost, and why does it matter?

Question

IT Interview Practice · Accepted Answer

A **context switch** is the kernel saving the currently running thread's CPU state (registers, program counter, stack pointer) and restoring another thread's, so a single core can multiplex many threads. It happens on every scheduler preemption, blocking syscall, or interrupt — and it isn't free.

## Where the cost hides

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

The **direct** cost is a few microseconds. The **indirect** cost — a cold cache and TLB after the switch — is frequently the bigger hit: the incoming thread runs slowly for a while as it re-warms its caches from main memory (tens to hundreds of cycles per miss).

## Thread vs process switch

Switching between **threads of the same process** is cheaper: they share an address space, so the page table (and the TLB, on hardware without tagged TLBs / PCIDs) need not change. Switching **processes** additionally reloads the page-table base register and traditionally flushes the TLB — which is why it costs more.

## Why it matters in practice

- **Too many threads** → the scheduler thrashes, spending cycles switching rather than working; past a point, more threads than cores *reduces* throughput.
- It's the core argument for **async / event-loop** models (Node, nginx, `io_uring`) and **goroutines / green threads**: handle many connections with few OS threads, avoiding a switch per request.
- It's why **CPU pinning / affinity** helps latency-sensitive services — keep a thread on one core to preserve its warm cache.
- A high involuntary context-switch count (visible in `vmstat`, `pidstat`) is a classic symptom of lock contention or CPU oversubscription.

## Why it matters

This is a senior-level question because it separates people who know the *term* from those who understand *why* it's expensive — and the real answer (cache/TLB pollution, not just register saves) drives architectural decisions: async I/O over thread-per-request, right-sizing thread pools to core count, and using affinity. It ties scheduling, virtual memory, and CPU caches into one performance story.

Where the cost hides

Thread vs process switch

Why it matters in practice

Why it matters

Related questions