Context Switching

01 Introduction

Every time the operating system decides to run a different process, it must perform a small miracle: suspend one running computation mid-instruction, save everything about it, restore a completely different computation whose state was saved earlier, and resume it as if no interruption had occurred. This operation is the context switch.

Context switching is what makes preemptive multitasking possible. Without it, a process would run until it voluntarily gave up the CPU, and the operating system would have no way to enforce fairness, respond to interrupts, or protect one process from another's monopolisation. With it, the machine can give every process the illusion of a private CPU while dozens of processes share one physical core.

But context switching is not free. Every switch consumes CPU cycles that could have been used for useful work, and it also pollutes the CPU caches and the TLB in ways that degrade the incoming process's performance for some time after the switch. This lesson examines what a switch involves, why it costs, how to measure the cost, and what that cost means for scheduling policy. It closes Unit 3 by tying together the process model, the state model, the PCB, and the scheduler.

02 Learning objectives

This lesson contributes to U3.5 and to course learning outcomes CLO3 and CLO6. It completes Unit 3.

03 Required reading

• Operating System Concepts — Chapter 3, Section 3.4 (Context Switch). The classical description of what happens on a switch and where the cost comes from.
• OSTEP — Chapter 6, Mechanism: Limited Direct Execution. How a system call traps into the kernel and how the kernel performs a context switch — the mechanism behind everything this lesson discusses.
• Love, R. — Linux Kernel Development, 3rd ed., Chapter 4, the section on context switching. Linux's implementation of the switch, including the context_switch() function and the difference between switching between processes and switching between threads.
• Linux man pages: man 1 vmstat, man 1 pidstat, man 1 perf-stat, man 5 proc (the ctxt_switches field in /proc/<pid>/status).

04 Core content

4.1 What a context switch is

A context switch is the act of saving the state of one process and restoring the state of another, so that the second process can resume where it previously left off.

The "state" saved and restored is precisely the process context from Lesson 3.3: the register values, the program counter, the stack pointer, and the memory-management information that tells the MMU how to translate virtual addresses. When the kernel finishes the switch, the CPU's registers hold the values the incoming process had at the moment it was last suspended, and its next instruction is the one it was about to execute.

The key insight is that a context switch is a change in which process is running, not a change in what the process is doing. The incoming process resumes mid-computation, with no awareness that anything happened. From its perspective, it has simply been executing continuously since it last ran. This is the illusion that makes multiprogramming work.

4.2 When context switches happen

A context switch never occurs spontaneously. It is always the consequence of a decision or an event. The four triggers correspond exactly to the four scheduling decision points from Lesson 3.4:

• A blocking system call. The running process calls read, wait, or a similar operation that cannot complete immediately. The process enters the Blocked state, and the kernel must select another ready process. Running → Blocked followed by a switch.
• A timer interrupt. The hardware timer fires, the kernel's timer handler runs, and the scheduler decides another process should run. This is the mechanism by which preemption happens — the transition Running → Ready from Lesson 3.2. The switch is involuntary from the process's point of view.
• An I/O completion interrupt. A device finishes an operation, its interrupt handler moves a blocked process back to Ready, and the scheduler may decide to preempt the current process in favour of the newly runnable one. Blocked → Ready, followed by a possible switch.
• Process termination. The running process exits. The CPU is now idle and the kernel must select another process. Running → Terminated followed by a switch.

On a modern general-purpose system, these events occur frequently. A loaded server may perform hundreds of thousands of context switches per second, each one a small operation that the kernel performs as part of normal operation. It is the cumulative cost of all of them that matters, not the cost of any single one.

4.3 The steps of a context switch

A simplified account of what the kernel does between two processes — A (outgoing) and B (incoming):

Several details deserve comment.

• The kernel runs on the incoming process's kernel stack. On modern kernels, each process has its own kernel stack — a small region of kernel memory used while executing system calls and interrupt handlers on that process's behalf. During a switch, the scheduler and the interrupt handlers execute on that stack. This keeps the user's stack intact and prevents a system-call-heavy process from consuming unbounded kernel stack space.
• Where the saved state is kept varies. On some architectures, the incoming process's registers are restored from a dedicated CPU-state area referenced by a per-CPU variable. On others — and on Linux in particular — the state is saved on the kernel stack, and switching stacks is what actually performs the context switch.
• The memory map change is expensive. On older architectures, switching page tables required flushing the TLB (translation lookaside buffer), which is a hardware cache of recent address translations. A flushed TLB means every subsequent memory access misses and must walk the page table — a serious slowdown that persists for thousands of instructions after the switch.
• Modern hardware mitigates this. ASIDs (Address Space Identifiers) tag each TLB entry with the process it belongs to, so switching between processes does not require a full flush. This substantially reduces the true cost of a context switch on modern CPUs, though it does not eliminate it: the incoming process's working set is still not in the cache.

4.4 Sources of overhead

The overhead of a context switch comes from several distinct sources, and it is important to distinguish them because they have different characteristics and different implications.

4.5 Context switch versus mode switch

A term that is frequently confused with context switch is mode switch. They are not the same thing, and the distinction matters for performance analysis.

Mode switch

A change of privilege level within the same process. When a process issues a system call, the CPU traps from user mode to kernel mode, runs the kernel code, and returns to user mode. The process itself is unchanged — it is the same process, with the same memory map, the same registers (mostly), and the same scheduling state. A mode switch costs a few hundred cycles: a trap, a save of some registers, a return.

Context switch

A change of process. The kernel saves one process's state, restores another's, and switches the memory map. This involves two mode switches (into the kernel and out of it) plus the save-and-restore work in between, plus the cache and TLB pollution that follows. A context switch is a strictly larger operation than a mode switch, typically 5–10× more expensive in direct cost.

A system call that completes quickly requires only a mode switch. A system call that blocks requires a mode switch and a context switch. This is why blocking system calls are more expensive than non-blocking ones, and why programs that avoid blocking calls where possible run faster.

4.6 Thread context switches

A preview of Unit 4: a context switch between two threads of the same process is much cheaper than a switch between two different processes. Because threads share the same address space, the memory map does not need to change — no page table switch, no CR3 write, no TLB flush. Only the registers and the stack pointer change. And because the threads share the same working set — the same code, data, and heap — the cache pollution is much less severe; the incoming thread is likely to find much of what it needs already in the cache.

The direct cost of a thread switch is typically about half that of a process switch, and the indirect cost is often a small fraction. This is one of the main performance arguments for threads over processes: a thread switch is often several times cheaper than a process switch, and modern multithreaded servers rely on this to handle high request rates.

We will return to this distinction in Unit 4, when we examine the thread model itself. For now, the important point is that "context switch" is not one operation but a family of operations whose cost depends on what is being switched.

4.7 Measuring context switches

Linux exposes context-switch counts through several interfaces. Learning to read them is a core diagnostic skill for the remainder of the course.

# Per-process: voluntary and involuntary context switches
$ grep ctxt /proc/$$/status
voluntary_ctxt_switches:     17
nonvoluntary_ctxt_switches:  3

# System-wide: the "cs" column of vmstat shows switches per second
$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 4123456  98234 982344    0    0     4     8   87  143  1  1 98  0  0
 1  0      0 4123444  98234 982344    0    0     0     0  102  168  1  1 98  0  0
# The "cs" column is context switches per second.
# The "in" column is interrupts per second.

# Per-process: cswch/s (voluntary) and nvcswch/s (involuntary)
$ pidstat -w 1
Linux 6.5.0 ...        10/15/2024     _x86_64_    (4 CPU)

14:22:01  UID  PID   cswch/s nvcswch/s  Command
14:22:02 1000 1234      0.99      0.00  bash
14:22:02 1000 5678      5.00      0.00  code
14:22:02 1000 9012      0.00     12.34  yes

# System-wide cumulative count since boot
$ cat /proc/schedstat | head -1
version 15
# The 11th field is the total number of context switches.
$ awk 'NR==1 {print "switches:", $10}' /proc/schedstat
switches: 128453921

The distinction between voluntary and involuntary context switches is important:

• A voluntary switch occurs when the process blocks on a system call — it chose to give up the CPU. The kernel's schedule() was called by the process itself (or by the kernel on its behalf as it entered a blocking path).
• An involuntary switch occurs when the process is preempted — the CPU was taken away. The kernel's timer handler or another preemption source forced the switch.

A high rate of involuntary switches usually means the process is competing for CPU with other CPU-hungry processes. A high rate of voluntary switches usually means the process is I/O-bound — it is blocking frequently and yielding the CPU each time.

4.8 Why the cost matters for scheduling

The cost of a context switch is not merely an implementation detail — it directly constrains what scheduling policies make sense. Every policy decision must weigh the benefit of running the "right" process against the cost of switching to it.

• Short time slices. Round-robin schedulers use a fixed time quantum. If the quantum is too small, the fraction of CPU time spent on context switches becomes significant. For example, if a switch costs 5 μs and the quantum is 100 μs, then 5% of every slice is overhead — and with hundreds of ready processes, the queueing delay compounds.
• Preemption frequency. A scheduler that preempts on every interrupt may achieve excellent response times at the cost of many context switches. A scheduler that waits for a running process to block avoids switches but may allow a CPU-bound process to monopolise the CPU.
• Cache locality. A process that is left to run for a longer period builds up warm caches and benefits from them. Frequent preemption destroys this benefit, which is why modern schedulers favour slightly longer quanta when the system is not under load.
• Switching cost differential. A scheduler aware that thread switches are cheaper than process switches may prefer to switch threads when possible — an idea that modern language runtimes exploit with lightweight tasks.

The trade-off between quantum size, response time, and throughput is exactly the throughput-versus-latency trade-off from Lesson 3.4. Unit 5 examines how practical schedulers resolve it — the answer is not a single quantum value but a set of heuristics that adapt the quantum to the workload.

4.9 The illusion of concurrency

Stepping back, it is worth reflecting on what the context switch accomplishes in a larger sense. On a single-core CPU, only one process executes at any instant. Yet the user's experience is of many processes running simultaneously — a browser rendering a page while a music player streams audio while a backup runs in the background. This experience is a carefully constructed illusion.

The illusion depends on three things:

1. Speed. Context switches happen far faster than a human can perceive. Switching between processes every few milliseconds means each process is running for a brief slice many times per second — enough to keep the user's perception of continuous progress intact.
2. Blocking. Most processes block on I/O frequently, so the scheduler is not preempting them mid-computation but rather dispatching them when they have work to do. A music player consumes only a small fraction of the CPU; between its brief bursts, the CPU is free for other work.
3. Aggregation. The combined effect of many short bursts from many processes is an apparently continuous multi-tasking experience. The user never sees the switching; they only see the output.

On multicore systems, the illusion becomes partially real: truly simultaneous execution happens across cores, and the context switch is what allows more processes than cores to share the machine. But even on multicore systems, the context switch is essential — it is what allows the number of runnable processes to exceed the number of cores.

4.10 Linux's implementation

Linux implements context switching in the function context_switch(), defined in kernel/sched/core.c. The function performs two distinct operations:

• switch_mm() — switches the memory map. On x86-64 this writes the new process's page-table base to the CR3 register. If the incoming and outgoing processes share the same mm — because they are threads of the same process — this step is effectively a no-op.
• switch_to() — switches the processor state and the kernel stack. This is architecture-specific code, usually a small assembly routine, because it must manipulate the stack pointer and the instruction pointer in ways that C cannot express.

The function has one more important property: it uses lazy TLB flushing. When switching to a process that has recently run, the kernel may skip the TLB flush entirely if it knows the old entries are still valid — for example, if the process is being resumed after a short preemption and the previous process's address space is unlikely to conflict. Modern hardware's PCID (Process Context Identifier) feature lets the CPU tag TLB entries with a process identifier, so a switch does not require flushing at all — the CPU simply starts using entries tagged with the new process's PCID.

The Linux context switch is one of the most carefully optimised pieces of code in the kernel. It runs hundreds of thousands of times per second on busy systems, and every instruction counts.

05 Worked example

To make the cost concrete, measure the actual context-switch overhead on your course VM.

#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>
#include <sys/time.h>

#define ITERATIONS 100000

/* A pair of pipes connecting the parent and child */
int to_child[2];
int to_parent[2];

static double now(void) {
    struct timeval tv;
    gettimeofday(&tv, NULL);
    return tv.tv_sec + tv.tv_usec / 1e6;
}

int main(void) {
    if (pipe(to_child) < 0 || pipe(to_parent) < 0) {
        perror("pipe");
        return 1;
    }

    pid_t pid = fork();
    if (pid < 0) {
        perror("fork");
        return 1;
    }

    if (pid == 0) {
        /* Child: receive, send back */
        char c;
        for (int i = 0; i < ITERATIONS; i++) {
            if (read(to_child[0], &c, 1) != 1) break;
            write(to_parent[1], &c, 1);
        }
        return 0;
    } else {
        /* Parent: send, receive back */
        char c = 'x';
        double start = now();
        for (int i = 0; i < ITERATIONS; i++) {
            write(to_child[1], &c, 1);
            read(to_parent[0], &c, 1);
        }
        double elapsed = now() - start;
        wait(NULL);

        printf("iterations:      %d\n", ITERATIONS);
        printf("total time:      %.3f s\n", elapsed);
        printf("time per round:  %.3f μs\n", (elapsed * 1e6) / ITERATIONS);
        printf("per switch:      %.3f μs  (round trip / 2)\n",
               (elapsed * 1e6) / (2 * ITERATIONS));
    }
    return 0;
}

$ gcc -Wall -Wextra -g -O2 -o ctx ctx.c
$ ./ctx
iterations:      100000
total time:      0.712 s
time per round:  7.120 μs
per switch:      3.560 μs  (round trip / 2)

process-based (fork + pipes):    3.56 μs per switch
thread-based (pthreads + cv):    1.42 μs per switch
speedup:                         ~2.5×

# Quiet system:
$ time ./benchmark
real    0m10.12s
user    0m10.11s
sys     0m0.01s

# With four competing processes:
$ for i in 1 2 3 4; do yes > /dev/null &; done
$ time ./benchmark
real    0m14.87s
user    0m10.13s
sys     0m4.62s
$ kill %1 %2 %3 %4

# The "sys" time (4.62 s) is time spent in the kernel,
# primarily on context switches and scheduler work.
# The wall-clock time has increased by nearly 50%
# even though the useful work (10.13 s user time) is unchanged.

06 Interactive activity

07 Knowledge check

08 Unit discussion

09 Practice exercise

10 Summary

• A context switch saves one process's state and restores another's, so the second can resume where it left off.
• Switches are triggered by blocking system calls, timer interrupts, I/O completion interrupts, and process termination — the same events that trigger scheduling decisions.
• The steps are: enter the kernel, save the outgoing state, run the scheduler, restore the incoming state, switch the memory map, return from the trap.
• Overhead comes from both the direct cost (executing the switch) and the indirect cost (cache and TLB pollution). The indirect cost often dominates and can raise the effective cost to 5–10× the direct measurement.
• A mode switch changes privilege level within one process; a context switch changes which process is running. The two are commonly confused but are distinct operations.
• Thread switches within a process are cheaper than process switches, because the address space and memory map stay the same.
• Context-switch cost constrains scheduling policy: short quanta improve response time at the cost of switching overhead, while long quanta do the opposite.
• Linux measures context switches through /proc/<pid>/status, vmstat, pidstat, and /proc/schedstat. Voluntary versus involuntary rates are a signature of a process's workload profile.

11 References

• Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts, 10th ed., Chapter 3, Section 3.4.
• Arpaci-Dusseau, R. H., & Arpaci-Dusseau, A. C. Operating Systems: Three Easy Pieces, Chapter 6. Available online at ostep.org.
• Love, R. Linux Kernel Development, 3rd ed., Chapter 4 (Process Scheduling), the section on context switching. Addison-Wesley, 2010.
• Linux kernel source: kernel/sched/core.c (context_switch(), switch_mm()), arch/x86/include/asm/switch_to.h (the architecture-specific switch_to()).
• Linux man-pages: man 1 vmstat, man 1 pidstat, man 1 perf-stat, man 5 proc.
• Li, C., Ding, C., & Shen, K. Quantifying the Cost of Context Switching in Current Multiprocessor Systems. Technical report, Lehigh University, 2013.
• Bach, M. J. The Design of the UNIX Operating System, Chapter 6. Prentice Hall, 1986. (Classical description of the context switch mechanism.)