Context Switch

Updated September 30, 20263 min read

In short

A context switch is when the operating system saves the state of the running thread or process and restores another one's state so it can use the CPU.

What is a context switch?

A CPU core can run only one thread at a time, so when many threads want to run, the operating system takes turns between them. A context switch is the act of swapping one out and another in. The context is everything needed to resume a task later exactly where it stopped: the CPU registers, the program counter, the stack pointer, and, for a process, its memory mappings.

A switch happens when a thread's time slice ends and a timer interrupt fires, when a thread blocks because it is waiting for disk or network I/O, a lock, or a sleep, or when a higher-priority thread becomes ready. The kernel saves the current thread's registers, the scheduler picks the next thread, and the kernel loads that thread's saved registers. If the next thread belongs to a different process, the kernel also switches to that process's page tables. The switch itself takes only microseconds, but the hidden cost is larger: the new thread starts with cold CPU caches and address translations, so it runs slowly for a while.

Picture a chef cooking several dishes at once. To move from the soup to the pasta, she notes where she was in the soup recipe, sets the pot aside, and picks up her pasta notes. If she switches every few seconds, she spends more time on bookkeeping than on cooking. That is why servers with thousands of threads can waste much of their CPU time on switching, and why event loops, async I/O, and thread pools are popular for handling many connections.

A context switch is not the same as CPU scheduling: scheduling is the decision about which task runs next, and the context switch is the mechanism that carries out that decision. It also differs from the mode switch in a system call, where the same thread moves from user mode into the kernel and back without another thread taking over, which is much cheaper. Switching between threads of the same process is also cheaper than switching between processes, because the memory mappings stay the same.

Key takeaways

A context switch saves one task's CPU state and restores another's.
It is triggered by time slices ending, blocking I/O, locks, or higher-priority work.
The direct cost is microseconds, but cold caches add hidden overhead.
Too many switches waste CPU time, which is why event loops and thread pools exist.
Scheduling decides what runs next; the context switch makes it happen.

Example

Measuring context switches on Linuxbash

# System-wide context switches per second (the "cs" column)
vmstat 1 5

# Voluntary (blocked) vs involuntary (preempted) switches for this shell
grep ctxt_switches /proc/$$/status

# Per-process switch rates, once per second (from the sysstat package)
pidstat -w 1 5

Readers ask

Why are context switches expensive?

Saving and loading registers is quick, but the new task finds the CPU caches and address translation buffers filled with the previous task's data. Until they warm up again, memory accesses are much slower.

What is the difference between voluntary and involuntary context switches?

A voluntary switch happens when a thread gives up the CPU itself, for example to wait for I/O or a lock. An involuntary switch happens when the scheduler preempts a thread that still wanted to run, usually because its time slice ended.

Is switching threads cheaper than switching processes?

Yes. Threads in the same process share one address space, so the kernel does not need to switch page tables, and more of the cached data stays useful.