Unix - UNIX Context Switching: How the Kernel Switches Between Processes

Context switching is the mechanism used by the UNIX operating system to stop the execution of one process or thread temporarily and allow another process or thread to use the CPU. Since a CPU core can execute only one instruction stream at a time, the operating system rapidly switches between runnable tasks to create the appearance that many programs are running simultaneously.

A context switch is mainly performed by the kernel, which saves the execution state of the currently running task and restores the previously saved state of another task. The saved state is commonly called the context. It can include CPU registers, the program counter, stack-related information, processor status information, and other architecture-dependent state. Once the new context is restored, the CPU continues executing the selected process from essentially the point where it was previously interrupted.

Why Context Switching Is Needed

A UNIX system normally has many processes competing for CPU time. For example, a user may have a web browser, terminal, text editor, background services, and system processes running simultaneously. The CPU scheduler determines which runnable process should receive CPU time.

Context switching becomes necessary when the currently running process should no longer continue using the CPU. This can happen for several reasons. A process may use up its allocated CPU time, voluntarily give up the processor, become blocked while waiting for input or another resource, or be interrupted so that a higher-priority task can run.

For example, suppose Process A is executing on a CPU and then requests data from a disk. Because disk access may take considerably longer than CPU execution, the kernel can place Process A into a waiting state and switch the CPU to Process B. When the required data becomes available, Process A can become runnable again and may eventually receive CPU time.

What Happens During a Context Switch

A simplified context-switch sequence can be understood in several stages.

First, an event causes the kernel to regain control of the CPU. This event may be a timer interrupt, system call, hardware interrupt, or another scheduling-related event.

Second, the kernel identifies the currently executing process and preserves the CPU state associated with it. Important information such as register values and the instruction location must be retained so that the process can continue correctly later.

Third, the scheduler evaluates the available runnable processes and selects another task according to the operating system's scheduling policies.

Fourth, the kernel loads the saved CPU state belonging to the selected task. Memory-management information and other architecture-specific state may also need to be changed.

Finally, control is returned to the selected process. It continues execution from the location represented by its restored program counter.

Conceptually, the operation looks like this:

Process A running
       |
       | Interrupt / scheduling event
       v
Kernel saves Process A context
       |
       v
Scheduler selects Process B
       |
       v
Kernel restores Process B context
       |
       v
Process B continues running

The process itself does not normally need to know that the context switch occurred. From its perspective, execution simply appears to pause and later continue.

CPU Registers and the Process Context

CPU registers are particularly important during a context switch because they contain temporary information required for continuing program execution.

The program counter, sometimes called the instruction pointer, identifies the next instruction that should be executed. If it were not saved and restored correctly, the process could resume at the wrong location.

Other registers may contain calculation results, function arguments, stack information, memory addresses, and processor status information. The kernel therefore has to preserve the relevant processor state before allowing another task to use the CPU.

The exact context depends on the processor architecture. For example, an x86-64 system and an ARM64 system have different register sets and low-level mechanisms. Consequently, the details of context switching are architecture-dependent even though the basic operating-system concept remains the same.

Process Switching and Thread Switching

Context switching can occur between processes or between threads. These two situations are related but are not necessarily identical.

When switching between two processes, the kernel may need to change address-space-related information because the processes can have different virtual memory spaces. This can make a process-to-process switch more expensive.

Threads belonging to the same process generally share the same address space. Therefore, switching between threads of the same process may require changing less state than switching between completely separate processes. However, the exact cost depends on the UNIX-like operating system, processor architecture, threading implementation, and other factors.

Context Switching and the Scheduler

The scheduler decides which runnable task should execute next, while the low-level context-switching mechanism performs the actual transition between execution contexts.

A simplified example is:

Runnable processes:
    Process A
    Process B
    Process C

Scheduler selects Process A
        |
        v
Process A executes
        |
        v
Scheduling event occurs
        |
        v
Scheduler selects Process B
        |
        v
Context switches to Process B

The scheduler may consider factors such as priority, fairness, CPU usage, task state, and scheduling policy. The precise scheduling behavior varies among UNIX and UNIX-like operating systems.

Context Switches Caused by Blocking

One important reason for a context switch is blocking.

Consider a program that reads data from a terminal or file:

Process A requests input
        |
        v
No input is currently available
        |
        v
Process A becomes blocked
        |
        v
Kernel selects another runnable process
        |
        v
Process B executes

Instead of allowing the CPU to remain idle while Process A waits, the kernel can execute another runnable task. This improves overall CPU utilization.

When the required input eventually becomes available, Process A can be awakened and placed back into the runnable state.

Context Switching Due to Time Sharing

UNIX systems support multitasking through mechanisms that allow CPU time to be shared among runnable tasks.

A timer interrupt can periodically return control to the kernel. The scheduler can then determine whether another process should receive CPU time. If a different task is selected, a context switch occurs.

For example:

Time
------------------------------------------------>

Process A | Process A | Process B | Process B | Process C
          ^            ^            ^            ^
       scheduler    scheduler    scheduler    scheduler

This rapid switching allows interactive applications to remain responsive while background processes continue working.

Context Switch Overhead

A context switch is not free. The kernel must perform work to save and restore state, update scheduling information, and potentially perform architecture-specific memory-management operations.

Because of this overhead, excessive context switching can reduce system performance.

For example, suppose a CPU spends a significant amount of its time switching between tasks instead of executing useful application instructions. In that situation, overall throughput can decrease.

However, avoiding context switches entirely is not practical on a multitasking operating system. The objective is to balance responsiveness, fairness, throughput, and switching overhead.

Context Switching and CPU Caches

Context switching can also influence CPU-cache behavior.

Modern processors use several levels of cache to keep frequently accessed instructions and data close to the CPU. When execution moves from one task to another, the new task may access different memory locations and instructions. This can reduce cache effectiveness and cause additional memory accesses.

Process switches can also involve changes to virtual-memory-related processor state. Modern CPUs have mechanisms such as translation lookaside buffers to accelerate virtual-address translation, and operating systems use architecture-specific techniques to minimize the cost associated with switching address spaces.

Therefore, the actual cost of a context switch can be considerably more complicated than simply saving and restoring registers.

Context Switch Versus Mode Switch

A mode switch and a context switch are different concepts.

A mode switch occurs when the CPU changes privilege level, such as when a user program makes a system call and execution enters kernel mode. The same process may continue executing after the kernel operation completes.

A context switch, on the other hand, occurs when execution moves from one task to another.

For example:

User Process A
      |
      | System call
      v
Kernel mode
      |
      | Return
      v
User Process A

This is primarily a mode transition.

A context switch would look more like:

Process A
    |
    v
Kernel
    |
    v
Process B

The two mechanisms can occur together, but they should not be treated as identical.

Example in a UNIX System

Imagine a UNIX server running three tasks:

Process A: Web application
Process B: Database operation
Process C: Log processing

Process A is currently running. It makes a system call that causes it to wait for network data. The kernel determines that Process A cannot continue immediately.

The scheduler selects Process B. The kernel preserves Process A's execution context and restores Process B's context. Process B then continues executing.

Later, Process B may block while waiting for storage. The scheduler can then select Process C. After the network data becomes available, Process A becomes runnable again and may eventually be selected.

This process can occur thousands or millions of times during system operation, depending on the workload and system configuration.

Factors Affecting Context-Switch Performance

Several factors influence how expensive context switching is:

  1. Processor architecture: Different CPUs require different amounts of state to be saved and restored.

  2. Process versus thread switching: Switching between independent processes may require more address-space-related work.

  3. Memory-management mechanisms: Changes to virtual-memory state can affect performance.

  4. CPU cache behavior: Switching workloads can reduce cache locality.

  5. Number of runnable tasks: A heavily loaded system may require more scheduling decisions.

  6. Scheduling policy: Different policies can produce different switching patterns.

  7. Workload characteristics: Interactive, CPU-intensive, and I/O-intensive workloads behave differently.

Importance in UNIX System Administration

Understanding context switching is useful when diagnosing system performance problems. High context-switch activity can sometimes indicate excessive multitasking, inefficient application behavior, synchronization problems, or a workload containing many short-lived tasks.

System administrators and developers can monitor context-switch-related statistics using operating-system-specific performance tools. On Linux, for example, tools such as vmstat, pidstat, and /proc provide information that can help investigate scheduling and process activity.

However, a high number of context switches does not automatically mean that a system is performing poorly. Context-switch rates must be interpreted alongside CPU utilization, system load, I/O activity, latency, and application behavior.

Conclusion

UNIX context switching is a fundamental mechanism that enables multiple processes and threads to share CPU resources efficiently. The kernel saves the execution state of one task, allows the scheduler to select another runnable task, restores the selected task's state, and resumes its execution.

Although context switching is essential for multitasking, it introduces overhead through state management, scheduling activity, memory-management operations, and potential cache effects. Understanding how context switching works provides a strong foundation for learning UNIX process scheduling, kernel architecture, performance analysis, and system optimization.