Imagine a backend process is about to executing this line:

Before it executes the next instruction, the operating system pauses it and gives another process a turn on the CPU. When the original process resumes, perhaps minutes later, it must continue exactly where it left off, as if nothing happened.

To make that possible, the operating system must remember where execution stopped, the values in the CPU registers, which memory belongs to the process, which files it has open, and what permissions it has.

None of this live, changing information is stored in the program’s executable file.

Instead, the kernel maintains a record for every running process. Textbooks call this record the process control block, or PCB.

The PCB is the kernel's bookkeeping record for managing one process.

The name sounds like a single physical block containing everything about a process. That is a useful starting model, but real kernels usually divide the information among several connected data structures.

A program file describes initial instructions and data. It does not describe one particular execution.

Once a process exists, the kernel must be able to identify it and its parent, know which user it runs as, determine whether it is eligible to use a CPU, and remember where its execution should continue. It must also connect the process to its address space and open resources while accounting for the CPU time and other resources it consumes.

The answers change while the process runs. A process opens and closes files, consumes CPU time, changes its credentials in permitted ways, and acquires more memory. The PCB and the kernel objects it references form the authoritative record of that changing state.

Without this record, the kernel could start a program but could not safely pause it, resume it, account for its resource use, enforce its permissions, or release its resources when it terminates.

The PCB lives in protected kernel memory.

An application cannot directly edit its PCB to give itself a different identity, a higher priority, or access to another process's files. It must request allowed changes through operating-system interfaces, and the kernel validates those requests.

This separation matters for both security and correctness.

If a process could modify its file references or credentials without kernel checks, it could falsify its identity and resource ownership. Corrupting execution or scheduling fields could also make the kernel resume an invalid context or damage its view of the machine.

Applications can inspect selected process information through interfaces such as ps, system calls, and Linux's /proc filesystem. These interfaces expose a controlled view; they do not give applications raw access to the kernel's internal record.

The exact fields differ between operating systems and kernel versions. Conceptually, the information falls into a few stable categories.

The PCB does not necessarily store every item inline. It often holds a value for small, frequently used fields and a pointer or reference to a larger structure for complex resources.

A conceptual PCB might look like this:

This is explanatory pseudocode, not a structure copied from a particular kernel. Its important feature is the mixture of direct fields and references to other kernel objects.

The kernel needs a reliable way to distinguish one process from every other process. The familiar identifier is the process ID, or PID.

A PCB typically records or provides access to the process's PID, its parent process, the user and group identities under which it operates, and other identifiers used to organize related processes.

The PID is only one field in the bookkeeping. It is not the PCB itself.

When a tool asks the kernel about PID 6842, the kernel uses an internal lookup mechanism to find the corresponding process record. Textbooks often describe the kernel's collection of PCBs as the process table.

The word table is conceptual. A real kernel may use several lists, trees, hash tables, indexes, and per-CPU structures rather than one large array.

Parent information lets the kernel maintain relationships between process lifetimes. Credentials let it decide whether the process may open a file, inspect another process, bind to a protected resource, or perform an administrative operation.

These values are trusted because the kernel owns them. A program may request a credential change or discover its PID, but printing a different number or changing an environment variable does not change its kernel identity.

At any instant, the CPU uses registers to hold the process's immediate execution state.

The instruction pointer identifies the next instruction, while the stack pointer identifies the current top of the execution stack. General-purpose registers hold operands, addresses, and intermediate results. Processor flags record conditions and control information.

When the process is actively executing, the freshest values are in the CPU's physical registers. The kernel does not copy every register into the PCB after every instruction.

When execution must stop, the operating system preserves enough of that context in protected memory. When the process continues, the saved values are restored so that the CPU resumes at the correct instruction with the correct stack and intermediate results.

Conceptually:

The context moves in both directions between the same two places, which is what allows a process to be stopped and resumed without noticing the gap.

On real systems, saved register state may live partly in an architecture-specific context structure and partly on the process's kernel stack. The PCB contains or points to what the kernel needs to locate that state.

This execution snapshot is essential, but it is only one part of the PCB. Saving registers without remembering the process's address space and resources would not be enough to resume it correctly.

Many processes may be eligible to execute, while the machine has only a limited number of CPU cores.

For each schedulable execution context, the kernel needs bookkeeping such as:

This information is updated as the process executes, waits, becomes eligible again, or has its scheduling settings changed.

The PCB does not itself make scheduling decisions. It supplies the identity and per-process facts that the scheduler uses alongside system-wide policy and the state of other work.

Keeping this information in kernel memory prevents a CPU-hungry process from simply declaring itself the most important task on the system.

A process uses virtual addresses for its code, global data, heap, stacks, and mapped libraries.

The PCB does not contain all bytes in that address space. Instead, it contains or references the kernel's description of the address space.

That description tells the kernel which virtual address ranges exist, what permissions they have, which mappings contain code or data, and which page-table structures represent the current mappings.

The distinction is important:

The bookkeeping record does not contain the address space. It holds a reference to it, which is why the kernel can describe a process compactly while the memory it describes may be gigabytes.

The bookkeeping describes and locates the process's memory. It is not a second copy of that memory.

This is also why changing an ordinary variable does not require the kernel to rewrite the PCB. The variable lives in the process's address space. The PCB only connects the process identity to the address-space structures the kernel manages.

Processes interact with files, pipes, sockets, terminals, and devices through kernel-managed references.

The process record points to a table of its open resources. On Unix-like systems, a file descriptor is interpreted relative to this per-process table. For process 6842, descriptors 0 and 1 might refer to terminal input and output, descriptor 3 to server.log, and descriptor 4 to a network socket.

Another process may also use a descriptor numbered 3, but its descriptor table can map that number to a completely different object.

The kernel also tracks filesystem context such as the process's current working directory and root directory. This is why the same relative path can resolve differently in two processes:

The PCB does not contain the contents of every open file or socket buffer. It points to kernel objects that represent those resources. Several process records may deliberately refer to the same underlying object while retaining separate process identities.

The kernel associates actions with the process responsible for them.

When a process requests access to a file or tries to control another process, the kernel consults credentials associated with the caller. These commonly include user and group identities plus additional security information defined by the operating system.

The process's environment variable named USER is not authoritative:

This command changes a string visible to the application. It does not give the process root credentials, because the trusted identity remains in kernel-managed state.

The kernel also records time spent executing application and kernel code, start time, memory and I/O counters, and voluntary or involuntary execution switches.

Monitoring tools obtain their process metrics from this bookkeeping or from counters attached to the referenced kernel objects.

Configured limits are part of the same control model. A process cannot escape a kernel-enforced limit by clearing a variable in its own address space; the kernel consults its own trusted state whenever the process requests more of a controlled resource.

A PCB is not filled in once at process creation and left unchanged.

Different events update different parts of the record:

At the same time, the kernel does not mirror every operation performed by the program.

If the program adds two integers, changes a local variable, or rearranges an in-memory array, those changes ordinarily occur in CPU registers and the process's address space. The PCB is management metadata, not a trace of everything the program has done.

A useful mental model is a library catalog record. The record identifies a book, says where it belongs, and tracks its current status. It does not contain another copy of every page in the book.

Similarly, the PCB identifies and manages a process while pointing to the larger objects that make up its execution environment.

Consider a server process that asks the kernel to open the relative path config/settings.json.

To handle the request, the kernel needs several kinds of process-specific information:

The PCB and its referenced objects tie all of this state to one process identity.

A single operation can require all three to agree. The record is what lets the kernel check them together rather than one at a time.

This is why the process abstraction is useful to the kernel. A PID is not merely a label printed by ps; it leads to the complete set of trusted state needed to act on behalf of that process.

Textbooks often draw one PCB per process with every field inside one rectangle. That model clearly communicates the purpose of the data.

Linux uses a more distributed implementation.

Its central process descriptor is a kernel structure named task_struct. It contains important scheduling, identity, relationship, and accounting fields. It also contains pointers to other structures representing the address space, open files, filesystem context, credentials, event handling, and other resources.

Linux uses the word task because its schedulable object maps closely to a thread of execution. A multithreaded process has a task_struct for each thread, while those tasks can share process-wide objects such as an address space and file table.

Each task still needs its own execution and scheduling information because each thread can execute independently. The shared pointers avoid duplicating objects that belong to the process as a whole.

Saved CPU state is also architecture-dependent and may be stored on a kernel stack or in structures reached through the task descriptor. As a result, no single Linux structure is a perfect literal match for every box in a textbook PCB.

The reliable mapping is:

Textbook PCB = the kernel-maintained bookkeeping required to identify, schedule, protect, pause, resume, and clean up a process.

On Linux, task_struct is the center of that bookkeeping, not necessarily its entire physical storage.

Linux exposes selected process information through /proc/<PID>.

These entries look like files, but they are views generated from current kernel state. They are not the kernel's raw structures written to disk.

Start a process and save its PID:

Inspect a readable summary:

A typical result looks like the following, although the identifiers, memory size, and allowed CPUs will vary:

This one view combines several PCB categories:

Inspect the process's current directory:

Inspect its open file descriptors:

Ask ps for a combined view:

Different commands expose different projections of the same kernel-managed process state.

Finally, stop the process:

After the process's lifecycle is complete, /proc/<PID> disappears. The directory existed only as a view of a live kernel object; it was never a permanent directory stored on disk.

The process control block is the kernel's trusted bookkeeping for one process. It records or references identity, saved execution context, scheduling information, memory mappings, open resources, credentials, event state, accounting data, and limits.

The PCB is management metadata, not a copy of the process's entire address space. It lives in protected kernel memory and changes as the operating system manages the process.

In Linux, task_struct is the central task descriptor, while related state is distributed across a kernel stack and referenced structures. The enduring mental model is:

The PCB is everything the kernel must remember to manage a process correctly, whether or not that process currently controls a CPU.