Fundamentals 19 min read

Understanding Linux Process & Thread Context Switching: Concepts, Tools, and Performance Analysis

This article explains core operating‑system concepts such as processes, threads, their control blocks and contexts, details how CPU, process, and thread context switches and system calls work on Linux, and shows how to analyze them with vmstat, pidstat, and sysbench for performance tuning.

Ops Development Stories
Ops Development Stories
Ops Development Stories
Understanding Linux Process & Thread Context Switching: Concepts, Tools, and Performance Analysis

1 Process Concept

Process Definition

A process is an independent execution activity of a program on a data set in a concurrent environment, serving as the basic unit for OS resource allocation, protection, and execution.

PCB

The Process Control Block (PCB) is a data structure that uniquely identifies a process and stores all information the OS needs to manage it.

Process Context

User‑level context includes code, data, user stack, and shared memory; register context includes general registers, instruction pointer (IP), flags (EFLAGS), stack pointer (ESP); system‑level context includes the PCB (task_struct), memory management structures (mm_struct, vm_area_struct, pgd, pte), and kernel stack.

2 Thread Concept

Thread Context

In a multithreaded environment, a process consists of a resource part and a thread part. An image illustrates this division.

TCB

A thread is composed of a Thread Control Block (TCB), user stack, system stack, a set of processor state registers, and a private memory area.

3 Context

CPU Context

CPU registers are fast, small internal memory; the program counter stores the address of the next instruction to execute. Together they form the CPU context required before any task runs.

Process Context Switch

When the kernel loads a new system context, it must save the current process context. Context switches occur on interrupts, system calls, or explicit scheduling. Typical scenarios include process termination, resource shortage, I/O wait, higher‑priority preemption, and hardware interrupts.

A process ends and the scheduler selects another.

Insufficient resources cause the process to return to the run queue.

Waiting for I/O makes the process voluntarily sleep.

Higher‑priority processes preempt the current one.

Hardware interrupts suspend the current process.

Thread Context Switch

If the two threads belong to different processes, the switch is identical to a process context switch.

If they belong to the same process, only thread‑private data and registers change, making it cheaper than a cross‑process switch.

System Call

System call is a request from user‑space code to the kernel for privileged services, providing the interface between applications and the OS.

Typical Linux Implementation

On x86 Linux, system calls are invoked via

int 0x80

with a call number placed in EAX. The steps are:

Application calls a library API.

The API loads the system‑call number into EAX and triggers an interrupt to enter kernel mode.

The kernel’s interrupt handler dispatches to the appropriate system‑call function.

The system call returns its result in EAX.

The interrupt handler returns to the API.

The API passes the return value back to the application.

Thus a single system call involves two CPU context switches—saving user registers, loading kernel registers, executing the kernel code, then restoring the user registers.

Interrupt Context Switch

Hardware interrupts, programmed interrupts, and exceptions are handled by the kernel, which saves the current context, creates a new one for the interrupt handler, processes the interrupt, and then restores the previous context.

4 Analyzing Linux CPU Context Switches

Tools

vmstat

vmstat reports overall system performance, including the number of context switches (cs) and interrupts (in) per second.

<code>$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0     0 27458868 145996 4781912    0    0     0     1    0    0  0  0 99  0  0
 0  0     0 27459388 145996 4781928    0    0     0     3 8937 15791  1  1 99  0  0
 0  0     0 27457272 145996 4781948    0    0     0    10 9022 15774  1  1 99  0  0</code>

Key columns: cs (context switches per second), in (interrupts per second), r (runnable processes), b (blocked processes).

For per‑process details, use

pidstat -w

(add

-p

to specify a PID).

<code># Every 5 seconds output one set of data
$ pidstat -wu -t 5
Linux 4.4.0-142-generic (i-0nxoa13q) 07/22/2021 _x86_64_ (16 CPU)

03:54:53 PM   UID      TGID       TID    %usr %system  %guest %CPU CPU Command
03:54:58 PM   0        3          -    0.00   0.20   0.00   0.20 0 ksoftirqd/0
... (output truncated) ...
03:54:58 PM   0        3          -    64.21   0.00  ksoftirqd/0
... (more output) ...
</code>

Two important columns:

cswch/s

(voluntary context switches) and

nvcswch/s

(non‑voluntary switches). High voluntary switches indicate resource contention (I/O, memory); high non‑voluntary switches indicate CPU saturation and forced scheduling.

proc Filesystem

The

/proc

pseudo‑filesystem provides runtime access to kernel data structures and settings; examining

/proc/interrupts

helps identify which interrupt sources dominate CPU time.

sysbench Stress Test

sysbench is an open‑source, modular, cross‑platform benchmark tool for CPU, memory, disk I/O, threads, and database performance.

<code># Run a 5‑minute benchmark with 10 threads to simulate multithreaded switching
sysbench --threads=10 --max-time=300 threads run
</code>

Sample

top

output shows high kernel CPU usage by sysbench, confirming CPU as the bottleneck.

<code>top - 11:10:05 up 10 days, 35 min, 3 users, load average: 2.72, 1.27, 0.64
Tasks: 120 total,   1 running, 119 sleeping, 0 stopped, 0 zombie
%Cpu0  : 22.3 us, 69.4 sy, 0.0 ni, 8.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
... (output truncated) ...
PID USER   PR  NI    VIRT    RES    SHR S %CPU %MEM    TIME+ COMMAND
18770 root  20   0   94368   3672   2696 S 378.4  0.0   2:43.48 sysbench
</code>

Using

pidstat -wu -t -p 18770

reveals many non‑voluntary context switches (≈150 k), indicating forced scheduling and that CPU is the system bottleneck.

How Many Context Switches Are Normal?

The acceptable range depends on CPU performance; stable, low‑CPU‑usage systems typically see around ten thousand switches with occasional spikes. Persistent high numbers together with high kernel CPU usage suggest performance problems.

Summary

Context switches occur in the kernel. When kernel CPU usage spikes, investigate context switches. Increased voluntary switches point to resource waits (I/O, memory); increased non‑voluntary switches indicate CPU contention. Rising interrupt counts imply the CPU is spending time handling interrupts, which can be examined via

/proc/interrupts

.

Linuxthreadsystem callProcessperformance analysiscontext switching
Ops Development Stories
Written by

Ops Development Stories

Maintained by a like‑minded team, covering both operations and development. Topics span Linux ops, DevOps toolchain, Kubernetes containerization, monitoring, log collection, network security, and Python or Go development. Team members: Qiao Ke, wanger, Dong Ge, Su Xin, Hua Zai, Zheng Ge, Teacher Xia.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.