PCB Contents: The Process Identity Card - Process Control Block (PCB) | OneNoughtOne

0/38

Operating SystemsProcess Control Block (PCB)

Process Control Block (PCB)

LevelIntermediate

Duration60 mins

TopicProcess Control Block (PCB)

1 / 5

PCB Contents: The Process Identity Card

The Kernel's View of a Process

When you launch a program—whether it's a web browser, a database server, or a simple command-line utility—the operating system doesn't see the same thing you see. You see windows, output, functionality. The kernel sees a Process Control Block (PCB): a data structure that captures everything the operating system needs to know about that running program.

The PCB is, in essence, the process's identity card within the kernel. Without it, the operating system couldn't schedule the process, couldn't resume it after an interrupt, couldn't allocate resources to it, couldn't even distinguish one process from another. Every single process in the system—from your web browser to the kernel's own worker threads—has an associated PCB.

Understanding the PCB is fundamental to understanding process management. It's where the abstract concept of a 'running program' meets the concrete reality of kernel data structures.

What You Will Learn

By the end of this page, you will understand the complete anatomy of a Process Control Block: what information it contains, why each field is necessary, how the PCB enables context switching and scheduling, and how different operating systems implement their PCB equivalents. You'll see the PCB not as an abstract concept but as a living data structure at the heart of every operating system.

What is the Process Control Block?

The Process Control Block (PCB), also known as the Task Control Block (TCB) or Process Descriptor, is the kernel data structure that stores all information about a single process. When a new process is created, the kernel allocates and initializes a new PCB. When the process terminates, the PCB is deallocated.

Formal Definition:

The Process Control Block is a per-process data structure maintained by the operating system kernel that contains all information necessary to manage and manipulate the process throughout its lifetime.

The PCB serves three fundamental purposes:

Process Identification: Uniquely identifying each process in the system
State Preservation: Storing the complete execution context so the process can be paused and resumed
Resource Tracking: Recording what resources (memory, files, devices) the process owns or is waiting for

The PCB as Process Representative

Think of the PCB as the process's ambassador to the kernel. When the scheduler needs to decide which process runs next, it examines PCBs, not actual processes. When a system call needs to validate permissions, it checks the PCB. The process itself never directly appears in kernel decision-making—only its PCB representation does.

Why does every process need a PCB?

Multiprogramming—running multiple processes concurrently—creates a fundamental challenge: how does the kernel track dozens, hundreds, or thousands of simultaneous processes? Each process exists in its own virtual world, with its own memory space, its own set of open files, its own execution state. Yet the kernel must manage all of them efficiently.

The PCB solves this by consolidating all per-process information into a single, manageable data structure. Instead of scattered information distributed throughout the kernel, each process's entire identity is captured in one place. This design enables:

Fast context switching: All information needed to switch from one process to another is in the PCB
Efficient scheduling: The scheduler can compare processes by examining their PCBs
Clean resource management: When a process terminates, the kernel knows exactly what to clean up by consulting the PCB
Debugging and monitoring: Tools like ps and top get their information by reading PCB data

Converting Mermaid diagram...

Anatomy of a Process Control Block

While PCB implementations vary between operating systems, they all contain the same fundamental categories of information. Let's dissect the PCB into its constituent parts:

Major Categories of PCB Contents
Category	Information Stored	Purpose
Process Identification	Process ID (PID), Parent PID, User ID, Group ID	Uniquely identify the process and its lineage; enforce permissions
Process State	Current state (new, ready, running, waiting, terminated)	Inform scheduler of process availability for execution
CPU Context	Program Counter, Stack Pointer, General Registers, Status Flags	Enable process suspension and resumption at exact point
CPU Scheduling Info	Priority, Scheduling Queue Pointers, CPU Time Used	Allow scheduler to make informed decisions
Memory Management Info	Page Tables, Base/Limit Registers, Segment Tables	Define the process's virtual address space
Accounting Information	CPU Time, Wall Clock Time, Time Limits	Track resource usage for billing and quotas
I/O Status	Open File Table, Allocated Devices, Pending I/O Requests	Track all I/O resources the process is using or waiting for

Detailed Breakdown of Each Category:

Process Identification

Every process needs a unique identity. The Process ID (PID) is typically a positive integer assigned sequentially or from a pool. On most systems, PIDs eventually wrap around and get reused, but only after the original process has fully terminated.

PID: The process's unique identifier (e.g., 1, 1024, 65432)
PPID (Parent PID): The PID of the process that created this one, establishing the process tree
UID (User ID): The user who owns this process—critical for access control
GID (Group ID): The primary group of the process owner
EUID/EGID (Effective): Used for privilege checks; may differ from real UID/GID when setuid/setgid is in effect

PID 1: The Special Case

On Unix-like systems, PID 1 is always the init process (systemd, init, or launchd)—the ancestor of all other user processes. It's special because it survives when parent processes die, adopting orphaned children. The kernel treats PID 1 differently: it cannot be killed by signals that would terminate other processes.

Process State

The state field records where the process is in its lifecycle. We'll explore states in depth in the next page, but here's the overview:

New: Process is being created
Ready: Waiting for CPU time; runnable but not currently running
Running: Currently executing on a CPU
Waiting/Blocked: Cannot proceed until an event occurs (I/O completion, signal, etc.)
Terminated/Zombie: Execution finished; PCB retained until parent collects exit status

CPU Context (Registers)

This is the heart of context switching. When a process is suspended, the kernel must save every CPU register so the process can resume exactly where it left off:

Program Counter (PC/RIP): Address of the next instruction to execute
Stack Pointer (SP/RSP): Top of the process's current stack
General-Purpose Registers: R0-R31 (ARM), RAX-R15 (x86-64), etc.
Floating-Point Registers: For floating-point and SIMD operations
Status/Flags Register: Condition codes, zero flag, carry flag, etc.
Segment Registers: On x86, selectors for code, data, and stack segments

We'll examine CPU context in detail in a later page.

linux_task_struct_simplified.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
// Simplified view of Linux's task_struct (the Linux PCB)
// Located in include/linux/sched.h
 
struct task_struct {
    // Process State
    volatile long state;         // Current state (-1 unrunnable, 0 runnable, >0 stopped)
    
    // Process Identification
    pid_t pid;                   // Process ID
    pid_t tgid;                  // Thread Group ID (for threading)
    
    // Process Relationships
    struct task_struct *parent;  // Pointer to parent's task_struct
    struct list_head children;   // List of child processes
    struct list_head sibling;    // Linkage in parent's children list
    
    // Credentials
    const struct cred *cred;     // Effective credentials (uid, gid, etc.)
    const struct cred *real_cred; // Real credentials
    
    // CPU Scheduling
    int prio;                    // Dynamic priority
    int static_prio;             // Static priority (set via nice)
    struct sched_entity se;      // Scheduling entity for CFS
    unsigned int policy;         // Scheduling policy (SCHED_NORMAL, SCHED_FIFO, etc.)
    
    // CPU Context (architecture-specific)
    struct thread_struct thread; // CPU register state (PC, SP, registers)
    
    // Memory Management
    struct mm_struct *mm;        // Memory descriptor (address space)
    struct mm_struct *active_mm; // Currently active address space
    
    // File System
    struct fs_struct *fs;        // Filesystem information (root, pwd)
    struct files_struct *files;  // Open file descriptor table
    
    // Signal Handling
    struct signal_struct *signal; // Shared signal state (for threads)
    struct sighand_struct *sighand; // Signal handlers
    sigset_t blocked;            // Blocked signals
    
    // Timing Information
    u64 utime;                   // User mode CPU time
    u64 stime;                   // Kernel mode CPU time
    u64 start_time;              // Process start time
    
    // ... hundreds more fields in the real implementation
};

PCB Implementations Across Operating Systems

Different operating systems implement the PCB concept with varying names, structures, and design philosophies. Understanding these variations reveals both the universal requirements and the design choices available.

Linux's Process Descriptor: task_struct

Linux calls its PCB the task_struct, reflecting its unified view of processes and threads (Linux considers threads to be 'lightweight processes'). The task_struct is defined in include/linux/sched.h and is one of the largest data structures in the kernel—typically several kilobytes in size.

Key Design Characteristics:

Monolithic Structure: Everything about a process is accessible through task_struct, either directly or via pointers
Thread Integration: Both processes and threads use task_struct; threads share certain fields (mm, files) but have separate CPU contexts
Dynamically Allocated: Each task_struct is allocated from a kernel memory pool (slab allocator)
Linked List Organization: All processes form a circular doubly-linked list for enumeration

linux_process_lookup.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// How Linux finds a process by PID
// (simplified from kernel/pid.c)
 
#include <linux/sched.h>
#include <linux/pid.h>
 
struct task_struct *find_task_by_vpid(pid_t pid) {
    struct pid *pid_struct;
    
    // PIDs are organized in a hash table for O(1) lookup
    pid_struct = find_vpid(pid);
    
    if (!pid_struct)
        return NULL;
    
    // Get the task_struct associated with this PID
    return pid_task(pid_struct, PIDTYPE_PID);
}
 
// Iterating through all processes
void iterate_all_processes(void) {
    struct task_struct *task;
    
    // for_each_process macro traverses the process list
    for_each_process(task) {
        printk(KERN_INFO "Process: %s, PID: %d, State: %ld
",
               task->comm, task->pid, task->state);
    }
}

Why task_struct is so Large

Linux's task_struct has grown to include hundreds of fields over decades of development: security modules, cgroups, namespaces, containers, tracing, perf events, and more. This is the cost of being a general-purpose OS that must support everything from embedded devices to supercomputers.

PCB Comparison Across Operating Systems
Aspect	Linux	Windows	macOS/XNU
PCB Name	`task_struct`	`EPROCESS`/`KPROCESS`	`proc` + `task`
Size (Approx.)	~6-8 KB	~4-8 KB	~1-2 KB each
Threads	Same structure (shared resources)	Separate `ETHREAD`	Separate `thread`
Security	Credentials struct	Access token	ucred struct
Memory	mm_struct	MADDRESS_SPACE	vm_map (Mach)
File Handles	files_struct	Handle table	filedesc (BSD)
Design Philosophy	Unified, monolithic	Layered, object-oriented	Hybrid, dual-layer

The Process Table: Organizing PCBs

Individual PCBs must be organized for efficient access. The process table is the kernel's collection of all PCBs—the master index of every process in the system. Different operations require different access patterns, so modern kernels use multiple data structures simultaneously.

Process Table Data Structures

•Linked List: For iterating through all processes (e.g., ps command). O(n) traversal, but allows unbounded number of processes.
•Hash Table (by PID): For fast PID lookup. When you call kill(pid, SIGTERM), the kernel must find the target in O(1) time.
•Tree Structure: For parent-child relationships. When a parent calls waitpid(), the kernel navigates the tree to find zombie children.
•Ready Queues: Scheduler-specific structures (priority queues, multi-level queues) for processes ready to run.
•Wait Queues: Lists of processes blocked on specific events (disk I/O, network, timers).

Converting Mermaid diagram...

Trade-offs in Process Table Design:

Historically, Unix systems used a fixed-size process table array. This had advantages (simple, O(1) access by index) but severe limitations (hard maximum on process count). Modern systems use dynamic allocation:

Approach	Pros	Cons
Fixed Array	Simple, fast access	Wastes memory, hard process limit
Linked List	Unbounded, easy insertion/deletion	O(n) search, poor cache locality
Hash Table	O(1) lookup, scalable	More complex, collision handling
Hybrid	Best of all worlds	Implementation complexity

Modern Linux uses a hybrid: a hash table keyed by PID for fast lookup, plus linked lists for iteration and tree structures for parent-child relationships. This allows efficient operations for all use cases.

PID Exhaustion

On 32-bit Linux, the maximum PID is 32768 by default (configurable up to ~4 million). On 64-bit systems, it can be much higher. PID exhaustion—running out of PIDs—crashes fork() with EAGAIN. This can happen in fork bomb attacks or systems that create many short-lived processes without reaping them.

PCB Lifecycle: Creation to Destruction

A PCB is born when a process is created and dies when the process is finally reaped. Understanding this lifecycle clarifies when and why PCB fields are populated.

PCB Lifecycle Stages

•Allocation: Kernel allocates memory for a new PCB from the slab allocator or memory pool. The PCB is initially zeroed or set to safe defaults.
•Initialization (fork/clone): PCB fields are populated. Some are copied from parent (credentials, file descriptors), others are new (PID, memory space). State is set to NEW.
•Ready Insertion: Once initialization completes, the process enters the READY state. The PCB is added to the scheduler's ready queue.
•Runtime Updates: As the process runs, the kernel continuously updates PCB fields: CPU time, state changes, open files, signal masks, etc.
•Context Saving/Restoring: On context switches, CPU registers are saved to/restored from the PCB's context area.
•Termination: When the process exits, it enters the TERMINATED/ZOMBIE state. Most resources are freed, but the PCB persists with the exit status.
•Reaping: Parent calls wait(). Kernel reads exit status from PCB, then deallocates the PCB. The process is now fully gone.

pcb_lifecycle_pseudocode.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
// Pseudocode illustrating PCB lifecycle
 
// 1. Process Creation (fork system call)
pcb_t* create_process(pcb_t* parent) {
    // Allocate new PCB
    pcb_t* child = allocate_pcb();
    
    // Generate new PID
    child->pid = allocate_pid();
    child->ppid = parent->pid;
    
    // Copy credentials from parent
    child->uid = parent->uid;
    child->gid = parent->gid;
    child->credentials = dup_credentials(parent->credentials);
    
    // Copy or share memory (copy-on-write)
    child->memory = copy_memory_space(parent->memory);
    
    // Copy file descriptor table
    child->files = dup_file_table(parent->files);
    
    // Initialize CPU context (for new execution)
    init_context(&child->context, entry_point);
    
    // Set initial state
    child->state = NEW;
    
    // Add to process table
    add_to_process_table(child);
    add_to_parent_children_list(parent, child);
    
    // Move to ready queue
    child->state = READY;
    add_to_ready_queue(child);
    
    return child;
}
 
// 2. Context Switch
void context_switch(pcb_t* old, pcb_t* new) {
    // Save current CPU state to old PCB
    save_registers(&old->context);
    old->state = READY;  // or WAITING if blocked
    
    // Switch address space
    switch_page_tables(new->memory);
    
    // Restore CPU state from new PCB
    restore_registers(&new->context);
    new->state = RUNNING;
    
    // Jump to execution (typically via return from interrupt)
}
 
// 3. Process Termination
void exit_process(pcb_t* current, int status) {
    // Close all open files
    close_all_files(current->files);
    
    // Release memory (except PCB itself)
    release_memory(current->memory);
    
    // Store exit status
    current->exit_status = status;
    
    // Reparent children to init
    reparent_children(current, init_process);
    
    // Enter zombie state
    current->state = ZOMBIE;
    
    // Signal parent
    send_signal(current->parent, SIGCHLD);
    
    // Schedule away (never returns)
    schedule();
}
 
// 4. Reaping (in wait system call)
int wait_for_child(pcb_t* parent, int* status) {
    // Find any zombie child
    pcb_t* zombie = find_zombie_child(parent);
    
    if (!zombie) {
        // Block until child exits
        block_current_process(WAITING_FOR_CHILD);
        schedule();
        zombie = find_zombie_child(parent);
    }
    
    // Collect exit status
    *status = zombie->exit_status;
    pid_t child_pid = zombie->pid;
    
    // Remove from process table
    remove_from_process_table(zombie);
    remove_from_parent_children(parent, zombie);
    
    // Release PID
    release_pid(child_pid);
    
    // Deallocate PCB
    free_pcb(zombie);
    
    return child_pid;
}

PCB and Context Switching

The PCB's most critical role is enabling context switching—the kernel's ability to suspend one process and resume another. Without the PCB's saved context, multitasking would be impossible.

What Gets Saved During a Context Switch:

When the kernel switches from Process A to Process B, it must save A's complete execution state so that A can resume as if nothing happened. This includes:

Context Switch: Save and Restore Operations
Category	Saved From CPU	Stored In PCB	Restore To CPU
Program Counter	RIP/PC register	context.pc	RIP/PC register
Stack Pointer	RSP/SP register	context.sp	RSP/SP register
General Registers	RAX, RBX, ... (all)	context.regs[]	RAX, RBX, ... (all)
Status Flags	RFLAGS/CPSR	context.flags	RFLAGS/CPSR
FP/SIMD Registers	XMM0-15, YMM0-15	context.fpu_state	XMM0-15, YMM0-15
Address Space	CR3/TTBR0	memory.page_table	CR3/TTBR0

Context Switch Speed Matters

Context switches happen thousands of times per second. On a server with 1000 active processes and a 100Hz timer, that's 100,000 context switches per second. Even microseconds of overhead add up. This is why context storage must be highly optimized—and why the PCB's context area is often accessed through assembly code.

Lazy Context Switching:

Not all context is saved eagerly. Modern systems use lazy saving for expensive state:

FPU/SIMD State: The floating-point unit (FPU) and vector registers (SSE, AVX) are large—up to 1KB for AVX-512. The kernel often defers saving this state: it marks the FPU as 'owned' by a process and only saves when another process tries to use the FPU.
Memory-Mapped State: The page table pointer (CR3 on x86) is always switched, but the actual page table entries remain in memory. The TLB (Translation Lookaside Buffer) is flushed or tagged to avoid stale translations.
Debug Registers: Breakpoint registers are only saved if the process is being debugged.

This lazy approach significantly reduces context switch overhead for the common case where processes don't use all CPU features.

Converting Mermaid diagram...

Viewing PCB Information

Operating systems expose PCB information through various interfaces. Understanding how to inspect process information connects the abstract PCB to practical system administration and debugging.

Linux exposes PCB information through the /proc virtual filesystem. Each process has a directory /proc/<pid>/ containing files that map to PCB fields.

linux_proc_exploration.sh
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# Explore a process's PCB information via /proc
 
# Get PID of current shell
echo "Current shell PID: $$"
 
# Process status (state, memory, threads)
cat /proc/$$/status | head -20
# Name:   bash
# State:  S (sleeping)
# Pid:    12345
# PPid:   12000
# Uid:    1000    1000    1000    1000
# Gid:    1000    1000    1000    1000
# Threads:        1
# VmPeak:    25000 kB
# VmSize:    24500 kB
# VmRSS:      5000 kB
 
# Open file descriptors (files_struct equivalent)
ls -la /proc/$$/fd/
# lrwx------ 1 user user 64 Jan 1 00:00 0 -> /dev/pts/0
# lrwx------ 1 user user 64 Jan 1 00:00 1 -> /dev/pts/0
# lrwx------ 1 user user 64 Jan 1 00:00 2 -> /dev/pts/0
 
# Memory maps (mm_struct equivalent)
cat /proc/$$/maps | head -5
# 5600a9a00000-5600a9a88000 r-xp 00000000 08:01 123456 /bin/bash
# 5600a9c87000-5600a9c8b000 r--p 00087000 08:01 123456 /bin/bash
# ...
 
# CPU context (limited - mainly scheduling info)
cat /proc/$$/stat
# 12345 (bash) S 12000 12345 12345 34816 12345 4194304 ...
 
# Detailed scheduling statistics
cat /proc/$$/sched

Summary: The Process Control Block

We've explored the Process Control Block from concept to implementation. Let's consolidate the key insights:

Key Takeaways

•The PCB is the kernel's representation of a process — It contains everything the OS needs to manage, schedule, and resume a process.
•PCBs contain multiple categories of information — Identification, state, CPU context, scheduling info, memory management, accounting, and I/O status.
•Different OSes implement PCBs differently — Linux uses task_struct, Windows uses EPROCESS, macOS uses proc+task. The concepts are universal; the structures vary.
•PCBs enable context switching — By saving and restoring CPU registers through the PCB, the kernel can multiplex processes on limited CPUs.
•PCBs are organized in tables — Hash tables for PID lookup, linked lists for iteration, trees for relationships—all optimized for different access patterns.
•You can inspect PCB contents — Through /proc, APIs, or debuggers, you can observe process state that directly reflects PCB fields.

What's Next:

Now that we understand the PCB's overall structure, we'll dive deeper into individual components. The next page examines the Process State field—how the kernel tracks whether a process is running, ready, blocked, or terminated, and the state machine that governs these transitions.

Page Complete

You now understand the Process Control Block: the kernel data structure that gives each process its identity and enables the operating system to manage thousands of concurrent processes. In the following pages, we'll examine each major PCB component in depth, starting with process state.

Operating SystemsProcess Control Block (PCB)

Process Control Block (PCB)

LevelIntermediate

Duration60 mins

TopicProcess Control Block (PCB)

1 / 5

PCB Contents: The Process Identity Card

The Kernel's View of a Process

Understanding the PCB is fundamental to understanding process management. It's where the abstract concept of a 'running program' meets the concrete reality of kernel data structures.

What You Will Learn

What is the Process Control Block?

Formal Definition:

The Process Control Block is a per-process data structure maintained by the operating system kernel that contains all information necessary to manage and manipulate the process throughout its lifetime.

The PCB serves three fundamental purposes:

Process Identification: Uniquely identifying each process in the system
State Preservation: Storing the complete execution context so the process can be paused and resumed
Resource Tracking: Recording what resources (memory, files, devices) the process owns or is waiting for

The PCB as Process Representative

Why does every process need a PCB?

Fast context switching: All information needed to switch from one process to another is in the PCB
Efficient scheduling: The scheduler can compare processes by examining their PCBs
Clean resource management: When a process terminates, the kernel knows exactly what to clean up by consulting the PCB
Debugging and monitoring: Tools like ps and top get their information by reading PCB data

Converting Mermaid diagram...

Anatomy of a Process Control Block

While PCB implementations vary between operating systems, they all contain the same fundamental categories of information. Let's dissect the PCB into its constituent parts:

Major Categories of PCB Contents
Category	Information Stored	Purpose
Process Identification	Process ID (PID), Parent PID, User ID, Group ID	Uniquely identify the process and its lineage; enforce permissions
Process State	Current state (new, ready, running, waiting, terminated)	Inform scheduler of process availability for execution
CPU Context	Program Counter, Stack Pointer, General Registers, Status Flags	Enable process suspension and resumption at exact point
CPU Scheduling Info	Priority, Scheduling Queue Pointers, CPU Time Used	Allow scheduler to make informed decisions
Memory Management Info	Page Tables, Base/Limit Registers, Segment Tables	Define the process's virtual address space
Accounting Information	CPU Time, Wall Clock Time, Time Limits	Track resource usage for billing and quotas
I/O Status	Open File Table, Allocated Devices, Pending I/O Requests	Track all I/O resources the process is using or waiting for

Detailed Breakdown of Each Category:

Process Identification

PID: The process's unique identifier (e.g., 1, 1024, 65432)
PPID (Parent PID): The PID of the process that created this one, establishing the process tree
UID (User ID): The user who owns this process—critical for access control
GID (Group ID): The primary group of the process owner
EUID/EGID (Effective): Used for privilege checks; may differ from real UID/GID when setuid/setgid is in effect

PID 1: The Special Case

Process State

The state field records where the process is in its lifecycle. We'll explore states in depth in the next page, but here's the overview:

New: Process is being created
Ready: Waiting for CPU time; runnable but not currently running
Running: Currently executing on a CPU
Waiting/Blocked: Cannot proceed until an event occurs (I/O completion, signal, etc.)
Terminated/Zombie: Execution finished; PCB retained until parent collects exit status

CPU Context (Registers)

This is the heart of context switching. When a process is suspended, the kernel must save every CPU register so the process can resume exactly where it left off:

Program Counter (PC/RIP): Address of the next instruction to execute
Stack Pointer (SP/RSP): Top of the process's current stack
General-Purpose Registers: R0-R31 (ARM), RAX-R15 (x86-64), etc.
Floating-Point Registers: For floating-point and SIMD operations
Status/Flags Register: Condition codes, zero flag, carry flag, etc.
Segment Registers: On x86, selectors for code, data, and stack segments

We'll examine CPU context in detail in a later page.

linux_task_struct_simplified.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
// Simplified view of Linux's task_struct (the Linux PCB)
// Located in include/linux/sched.h
 
struct task_struct {
    // Process State
    volatile long state;         // Current state (-1 unrunnable, 0 runnable, >0 stopped)
    
    // Process Identification
    pid_t pid;                   // Process ID
    pid_t tgid;                  // Thread Group ID (for threading)
    
    // Process Relationships
    struct task_struct *parent;  // Pointer to parent's task_struct
    struct list_head children;   // List of child processes
    struct list_head sibling;    // Linkage in parent's children list
    
    // Credentials
    const struct cred *cred;     // Effective credentials (uid, gid, etc.)
    const struct cred *real_cred; // Real credentials
    
    // CPU Scheduling
    int prio;                    // Dynamic priority
    int static_prio;             // Static priority (set via nice)
    struct sched_entity se;      // Scheduling entity for CFS
    unsigned int policy;         // Scheduling policy (SCHED_NORMAL, SCHED_FIFO, etc.)
    
    // CPU Context (architecture-specific)
    struct thread_struct thread; // CPU register state (PC, SP, registers)
    
    // Memory Management
    struct mm_struct *mm;        // Memory descriptor (address space)
    struct mm_struct *active_mm; // Currently active address space
    
    // File System
    struct fs_struct *fs;        // Filesystem information (root, pwd)
    struct files_struct *files;  // Open file descriptor table
    
    // Signal Handling
    struct signal_struct *signal; // Shared signal state (for threads)
    struct sighand_struct *sighand; // Signal handlers
    sigset_t blocked;            // Blocked signals
    
    // Timing Information
    u64 utime;                   // User mode CPU time
    u64 stime;                   // Kernel mode CPU time
    u64 start_time;              // Process start time
    
    // ... hundreds more fields in the real implementation
};

PCB Implementations Across Operating Systems

Linux's Process Descriptor: task_struct

Key Design Characteristics:

Monolithic Structure: Everything about a process is accessible through task_struct, either directly or via pointers
Thread Integration: Both processes and threads use task_struct; threads share certain fields (mm, files) but have separate CPU contexts
Dynamically Allocated: Each task_struct is allocated from a kernel memory pool (slab allocator)
Linked List Organization: All processes form a circular doubly-linked list for enumeration

linux_process_lookup.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// How Linux finds a process by PID
// (simplified from kernel/pid.c)
 
#include <linux/sched.h>
#include <linux/pid.h>
 
struct task_struct *find_task_by_vpid(pid_t pid) {
    struct pid *pid_struct;
    
    // PIDs are organized in a hash table for O(1) lookup
    pid_struct = find_vpid(pid);
    
    if (!pid_struct)
        return NULL;
    
    // Get the task_struct associated with this PID
    return pid_task(pid_struct, PIDTYPE_PID);
}
 
// Iterating through all processes
void iterate_all_processes(void) {
    struct task_struct *task;
    
    // for_each_process macro traverses the process list
    for_each_process(task) {
        printk(KERN_INFO "Process: %s, PID: %d, State: %ld
",
               task->comm, task->pid, task->state);
    }
}

Why task_struct is so Large

PCB Comparison Across Operating Systems
Aspect	Linux	Windows	macOS/XNU
PCB Name	`task_struct`	`EPROCESS`/`KPROCESS`	`proc` + `task`
Size (Approx.)	~6-8 KB	~4-8 KB	~1-2 KB each
Threads	Same structure (shared resources)	Separate `ETHREAD`	Separate `thread`
Security	Credentials struct	Access token	ucred struct
Memory	mm_struct	MADDRESS_SPACE	vm_map (Mach)
File Handles	files_struct	Handle table	filedesc (BSD)
Design Philosophy	Unified, monolithic	Layered, object-oriented	Hybrid, dual-layer

The Process Table: Organizing PCBs

Process Table Data Structures

•Linked List: For iterating through all processes (e.g., ps command). O(n) traversal, but allows unbounded number of processes.
•Hash Table (by PID): For fast PID lookup. When you call kill(pid, SIGTERM), the kernel must find the target in O(1) time.
•Tree Structure: For parent-child relationships. When a parent calls waitpid(), the kernel navigates the tree to find zombie children.
•Ready Queues: Scheduler-specific structures (priority queues, multi-level queues) for processes ready to run.
•Wait Queues: Lists of processes blocked on specific events (disk I/O, network, timers).

Converting Mermaid diagram...

Trade-offs in Process Table Design:

Approach	Pros	Cons
Fixed Array	Simple, fast access	Wastes memory, hard process limit
Linked List	Unbounded, easy insertion/deletion	O(n) search, poor cache locality
Hash Table	O(1) lookup, scalable	More complex, collision handling
Hybrid	Best of all worlds	Implementation complexity

PID Exhaustion

PCB Lifecycle: Creation to Destruction

A PCB is born when a process is created and dies when the process is finally reaped. Understanding this lifecycle clarifies when and why PCB fields are populated.

PCB Lifecycle Stages

•Allocation: Kernel allocates memory for a new PCB from the slab allocator or memory pool. The PCB is initially zeroed or set to safe defaults.
•Initialization (fork/clone): PCB fields are populated. Some are copied from parent (credentials, file descriptors), others are new (PID, memory space). State is set to NEW.
•Ready Insertion: Once initialization completes, the process enters the READY state. The PCB is added to the scheduler's ready queue.
•Runtime Updates: As the process runs, the kernel continuously updates PCB fields: CPU time, state changes, open files, signal masks, etc.
•Context Saving/Restoring: On context switches, CPU registers are saved to/restored from the PCB's context area.
•Termination: When the process exits, it enters the TERMINATED/ZOMBIE state. Most resources are freed, but the PCB persists with the exit status.
•Reaping: Parent calls wait(). Kernel reads exit status from PCB, then deallocates the PCB. The process is now fully gone.

pcb_lifecycle_pseudocode.c
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
// Pseudocode illustrating PCB lifecycle
 
// 1. Process Creation (fork system call)
pcb_t* create_process(pcb_t* parent) {
    // Allocate new PCB
    pcb_t* child = allocate_pcb();
    
    // Generate new PID
    child->pid = allocate_pid();
    child->ppid = parent->pid;
    
    // Copy credentials from parent
    child->uid = parent->uid;
    child->gid = parent->gid;
    child->credentials = dup_credentials(parent->credentials);
    
    // Copy or share memory (copy-on-write)
    child->memory = copy_memory_space(parent->memory);
    
    // Copy file descriptor table
    child->files = dup_file_table(parent->files);
    
    // Initialize CPU context (for new execution)
    init_context(&child->context, entry_point);
    
    // Set initial state
    child->state = NEW;
    
    // Add to process table
    add_to_process_table(child);
    add_to_parent_children_list(parent, child);
    
    // Move to ready queue
    child->state = READY;
    add_to_ready_queue(child);
    
    return child;
}
 
// 2. Context Switch
void context_switch(pcb_t* old, pcb_t* new) {
    // Save current CPU state to old PCB
    save_registers(&old->context);
    old->state = READY;  // or WAITING if blocked
    
    // Switch address space
    switch_page_tables(new->memory);
    
    // Restore CPU state from new PCB
    restore_registers(&new->context);
    new->state = RUNNING;
    
    // Jump to execution (typically via return from interrupt)
}
 
// 3. Process Termination
void exit_process(pcb_t* current, int status) {
    // Close all open files
    close_all_files(current->files);
    
    // Release memory (except PCB itself)
    release_memory(current->memory);
    
    // Store exit status
    current->exit_status = status;
    
    // Reparent children to init
    reparent_children(current, init_process);
    
    // Enter zombie state
    current->state = ZOMBIE;
    
    // Signal parent
    send_signal(current->parent, SIGCHLD);
    
    // Schedule away (never returns)
    schedule();
}
 
// 4. Reaping (in wait system call)
int wait_for_child(pcb_t* parent, int* status) {
    // Find any zombie child
    pcb_t* zombie = find_zombie_child(parent);
    
    if (!zombie) {
        // Block until child exits
        block_current_process(WAITING_FOR_CHILD);
        schedule();
        zombie = find_zombie_child(parent);
    }
    
    // Collect exit status
    *status = zombie->exit_status;
    pid_t child_pid = zombie->pid;
    
    // Remove from process table
    remove_from_process_table(zombie);
    remove_from_parent_children(parent, zombie);
    
    // Release PID
    release_pid(child_pid);
    
    // Deallocate PCB
    free_pcb(zombie);
    
    return child_pid;
}

PCB and Context Switching

The PCB's most critical role is enabling context switching—the kernel's ability to suspend one process and resume another. Without the PCB's saved context, multitasking would be impossible.

What Gets Saved During a Context Switch:

When the kernel switches from Process A to Process B, it must save A's complete execution state so that A can resume as if nothing happened. This includes:

Context Switch: Save and Restore Operations
Category	Saved From CPU	Stored In PCB	Restore To CPU
Program Counter	RIP/PC register	context.pc	RIP/PC register
Stack Pointer	RSP/SP register	context.sp	RSP/SP register
General Registers	RAX, RBX, ... (all)	context.regs[]	RAX, RBX, ... (all)
Status Flags	RFLAGS/CPSR	context.flags	RFLAGS/CPSR
FP/SIMD Registers	XMM0-15, YMM0-15	context.fpu_state	XMM0-15, YMM0-15
Address Space	CR3/TTBR0	memory.page_table	CR3/TTBR0

Context Switch Speed Matters

Lazy Context Switching:

Not all context is saved eagerly. Modern systems use lazy saving for expensive state:

FPU/SIMD State: The floating-point unit (FPU) and vector registers (SSE, AVX) are large—up to 1KB for AVX-512. The kernel often defers saving this state: it marks the FPU as 'owned' by a process and only saves when another process tries to use the FPU.
Memory-Mapped State: The page table pointer (CR3 on x86) is always switched, but the actual page table entries remain in memory. The TLB (Translation Lookaside Buffer) is flushed or tagged to avoid stale translations.
Debug Registers: Breakpoint registers are only saved if the process is being debugged.

This lazy approach significantly reduces context switch overhead for the common case where processes don't use all CPU features.

Converting Mermaid diagram...

Viewing PCB Information

Operating systems expose PCB information through various interfaces. Understanding how to inspect process information connects the abstract PCB to practical system administration and debugging.

Linux exposes PCB information through the /proc virtual filesystem. Each process has a directory /proc/<pid>/ containing files that map to PCB fields.

linux_proc_exploration.sh
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# Explore a process's PCB information via /proc
 
# Get PID of current shell
echo "Current shell PID: $$"
 
# Process status (state, memory, threads)
cat /proc/$$/status | head -20
# Name:   bash
# State:  S (sleeping)
# Pid:    12345
# PPid:   12000
# Uid:    1000    1000    1000    1000
# Gid:    1000    1000    1000    1000
# Threads:        1
# VmPeak:    25000 kB
# VmSize:    24500 kB
# VmRSS:      5000 kB
 
# Open file descriptors (files_struct equivalent)
ls -la /proc/$$/fd/
# lrwx------ 1 user user 64 Jan 1 00:00 0 -> /dev/pts/0
# lrwx------ 1 user user 64 Jan 1 00:00 1 -> /dev/pts/0
# lrwx------ 1 user user 64 Jan 1 00:00 2 -> /dev/pts/0
 
# Memory maps (mm_struct equivalent)
cat /proc/$$/maps | head -5
# 5600a9a00000-5600a9a88000 r-xp 00000000 08:01 123456 /bin/bash
# 5600a9c87000-5600a9c8b000 r--p 00087000 08:01 123456 /bin/bash
# ...
 
# CPU context (limited - mainly scheduling info)
cat /proc/$$/stat
# 12345 (bash) S 12000 12345 12345 34816 12345 4194304 ...
 
# Detailed scheduling statistics
cat /proc/$$/sched

Summary: The Process Control Block

We've explored the Process Control Block from concept to implementation. Let's consolidate the key insights:

Key Takeaways

•The PCB is the kernel's representation of a process — It contains everything the OS needs to manage, schedule, and resume a process.
•PCBs contain multiple categories of information — Identification, state, CPU context, scheduling info, memory management, accounting, and I/O status.
•Different OSes implement PCBs differently — Linux uses task_struct, Windows uses EPROCESS, macOS uses proc+task. The concepts are universal; the structures vary.
•PCBs enable context switching — By saving and restoring CPU registers through the PCB, the kernel can multiplex processes on limited CPUs.
•PCBs are organized in tables — Hash tables for PID lookup, linked lists for iteration, trees for relationships—all optimized for different access patterns.
•You can inspect PCB contents — Through /proc, APIs, or debuggers, you can observe process state that directly reflects PCB fields.

What's Next:

Page Complete