Understanding CPU Workloads: Processes, Threads, and Context Switching

CPU Workload Overview

From the operating‑system perspective the CPU executes instruction streams that originate from user processes, kernel threads, and interrupt handlers. The kernel runs in kernel mode while ordinary programs run in user mode . Transitions between the two modes occur via system calls (privilege‑mode switches).

Interrupt handling : hardware devices (network cards, disks, keyboards, etc.) raise interrupts. The CPU saves the current context, jumps to the interrupt service routine, and resumes the interrupted task after handling.

Exception handling : triggered by illegal memory accesses, privileged‑instruction faults, or software bugs. The kernel invokes an exception handler to recover or terminate the offending process.

System calls : user processes request kernel services (e.g., file I/O, memory allocation). The CPU switches to kernel mode, performs the operation, then returns to user mode.

Processes vs. Threads

A process owns an isolated address space, file descriptors, and other resources. A thread is an execution context that shares the process’s resources. The scheduler dispatches threads, not whole processes. Because a process switch must save and restore the full process state (memory mappings, open files, etc.), it incurs higher latency than a thread switch, which only needs to preserve thread‑local registers and stack.

Process Control Block (PCB) and Lifecycle

Each process is represented by a Process Control Block that stores the information required for management and scheduling:

Process ID (PID) – unique identifier.

Process state – created, ready, running, blocked, terminated.

Program counter – address of the next instruction to execute.

CPU registers – saved register values when the process is not running.

Memory‑management data – page tables, base/limit registers.

I/O status – list of open files, assigned devices.

Scheduling attributes – priority, queue pointers, CPU‑time accounting.

Utilities such as ps or top read these fields from the PCB. During a context switch the kernel copies the current PCB to memory and loads the next PCB, making the switch itself a potential performance bottleneck when it occurs frequently.

The typical lifecycle of a process follows:

Creation – allocation of a PCB, address space, and loading of executable code.

Ready – the process waits for the scheduler to assign CPU time according to policies (e.g., priority, round‑robin).

Running – the process executes; it may be pre‑empted, become blocked, or finish.

Blocked – the process is suspended (e.g., waiting for I/O or a signal).

Termination – the kernel reclaims resources and removes the PCB.

Understanding these states helps pinpoint why excessive context switches degrade CPU performance.

CPU Context Switching in Linux

Linux implements multitasking by rapidly switching the CPU between different execution contexts. Although a single core can execute only one instruction stream at a time, the high switch frequency creates the illusion of parallelism.

Three main types of context switches exist:

Process context switch : occurs when the scheduler selects a different process. The kernel saves the full PCB (including memory mappings) and restores the target PCB. This switch runs in kernel mode and is the most expensive.

Thread context switch : occurs between threads of the same process. Because threads share the address space and most resources, only thread‑specific registers and stack pointers need saving, making it considerably faster.

Interrupt/exception context switch : triggered by hardware events or faults. The CPU saves a minimal set of registers, executes the handler at a high priority, and then restores the previous context.

Frequent switches increase the proportion of CPU time spent on saving/restoring state, potentially exceeding the time spent executing actual workload. Monitoring tools (e.g., perf sched, trace-cmd) can expose switch frequency and latency, guiding performance‑tuning efforts.