After viewing Fireship’s recent video on operating system concepts, I wanted to go deeper into how an operating system actually works beneath the surface. This article is a culmination of the information I learned while studying the major abstractions, mechanisms, and trade-offs that make modern operating systems possible.

The goal is not to list every term as a disconnected glossary. The goal is to follow one complete execution path: a machine powers on, the kernel takes control, a user launches an application, the application performs work, the operating system schedules it, maps its memory, mediates its access to files and devices, isolates it from other workloads, and eventually persists its output.

That path is enough to explain the core ideas behind an operating system, kernel, process, thread, system call, scheduler, virtual memory, file system, device driver, interrupt, container, and virtual machine without reducing them to slogans.

1. The operating system as a control layer

An operating system is a privileged software layer that controls hardware resources and presents stable abstractions to user programs. It makes one physical machine appear as many independent execution environments. Each program gets the illusion of its own CPU timeline, address space, file table, and I/O channel, while the operating system multiplexes real CPUs, memory, caches, buses, storage devices, and network interfaces beneath that illusion.

The operating system has three central responsibilities:

Virtualization: turn physical resources into programmable abstractions.
Concurrency: allow many activities to progress without corrupting each other.
Persistence: store data beyond the lifetime of a process or power cycle.

These are not separate chapters in the life of a system. They overlap continuously. Opening a text editor touches process creation, virtual memory, scheduling, filesystem lookup, page cache behavior, permissions, device drivers, interrupts, and storage consistency. The operating system is the coordination boundary between all of them.

2. From power button to kernel

A computer does not begin by running an operating system. It begins by running firmware.

When the machine powers on, firmware performs early hardware initialization, discovers bootable devices, and transfers control to a bootloader. On modern PCs, this is usually handled through UEFI, which replaced the older BIOS model. UEFI maintains boot configuration, loads boot applications, and provides a structured pre-OS execution environment.

The bootloader’s job is narrower but critical: locate the operating system kernel, load it into memory, prepare boot parameters, and transfer control to the kernel entry point. In Linux systems, the bootloader commonly loads the compressed kernel image and an initial RAM filesystem, often called initrd or initramfs. This temporary userspace gives the kernel enough early tooling to discover disks, load storage drivers, unlock encrypted volumes, assemble root filesystems, and mount the real root filesystem.

Once the kernel is running, it initializes architecture-specific CPU state, memory management, interrupt handling, device discovery, scheduler structures, kernel threads, and core subsystems. After that, it starts the first userspace process. On Unix-like systems this process is historically called init; on many Linux distributions it is now systemd, running as process ID 1.

PID 1 is special. It is not just another process. It becomes the root of the userspace process tree, starts system services, manages daemons, handles orphaned child processes, and defines much of the system’s service lifecycle. From that point onward, the operating system is no longer only initializing itself. It is now managing work.

3. Kernel architecture: where the privileged boundary is drawn

The kernel is the privileged core of the operating system. It runs in a CPU mode that can access hardware, configure memory mappings, handle interrupts, and enforce protection boundaries. User programs run with fewer privileges and must request kernel services through controlled entry points.

Different operating systems draw the kernel boundary differently.


Kernel style	What runs in privileged kernel space	Main advantage	Main cost	Practical interpretation
Monolithic kernel	Most core OS services: scheduler, memory manager, filesystems, networking, drivers	Fast internal calls and tight integration	Larger trusted computing base; privileged bugs have wider impact	Linux is the canonical modern example
Microkernel	Minimal core: scheduling, IPC, low-level address-space management	Stronger fault isolation and modularity	IPC and service coordination dominate design	QNX, MINIX, and seL4 are common reference points
Hybrid kernel	A mixed design with microkernel ideas and monolithic practicalities	Balances modularity with performance	Boundary can be conceptually less clean	Windows NT and XNU are often described this way
Exokernel	Minimal resource protection; abstractions pushed to libraries	Maximum application-level control	More complexity in user-level runtime design	Important research model, less common in mainstream deployment

The boundary matters because the kernel is trusted. A crash in ordinary userspace usually kills one process. A crash in privileged kernel code can corrupt memory, lose data, break isolation, or bring down the entire system. Kernel architecture is therefore a design decision about performance, isolation, extensibility, and trust.

4. From executable file to process

A program stored on disk is passive. It becomes active only when the operating system creates a process.

A process is a running instance of a program. It contains execution state, virtual memory mappings, open file references, signal handlers, credentials, scheduling metadata, and other kernel-maintained state. The executable file contributes code and static data, but the process is more than the file. It is a live execution container.

A process normally contains at least one thread. A thread is a schedulable execution stream. Threads inside the same process share the process address space, file table, and many resources, but each thread has its own stack, register state, and scheduling identity.

The distinction is essential:


Concept	Owns address space?	Shares memory by default?	Scheduled by kernel?	Typical use
Process	Yes	No	Yes	Isolation between programs
Thread	No, shares process address space	Yes	Yes	Parallel or concurrent work inside one program

Processes isolate by default. Threads communicate by default. That is the first major design trade-off. Processes are safer but more expensive to coordinate. Threads are lighter but easier to corrupt through shared state.

On Unix-like systems, process creation is traditionally explained through three calls:

fork creates a new child process by duplicating the calling process.
exec replaces the current process image with a new program.
wait lets a parent observe child termination.

pid_t pid = fork();

if (pid == 0) {

execlp("ls", "ls", "-l", (char *)0);

_exit(127); // exec only returns on failure

}

waitpid(pid, NULL, 0);

Modern implementations optimize this path heavily. A fork() does not eagerly copy all memory. It typically uses copy-on-write, where parent and child initially share physical pages marked read-only. If either process writes to a shared page, the kernel creates a private copy. This allows fast process creation without immediately duplicating large address spaces.

5. File descriptors: small integers over kernel objects

When a process opens a file, socket, pipe, terminal, or device, it usually receives a file descriptor. A file descriptor is a small integer in the process. It indexes a per-process descriptor table, which points to kernel-managed open file descriptions.

This abstraction is one of the most important Unix design ideas. Many different resources can be accessed through the same basic operations: open, read, write, close, poll, dup, and related calls. A regular file, network socket, terminal, pipe, and device node are not the same internally, but they can expose compatible interfaces.

int fd = open("notes.txt", O_RDONLY);

char buf[4096];

ssize_t n = read(fd, buf, sizeof buf);

close(fd);

File descriptors also expose subtle OS behavior. For example, file descriptors can be inherited across process creation unless marked close-on-exec. That is useful for shells and pipelines, but dangerous in multithreaded programs if a descriptor accidentally leaks into a child process. A small integer in user space can therefore represent a security boundary, a lifetime boundary, and a concurrency hazard.

6. System calls: crossing into the kernel

A user program cannot directly program the disk controller, modify page tables, or mask hardware interrupts. It must ask the kernel to do privileged work. That request crosses the user/kernel boundary through a system call.

A system call is a controlled entry point into kernel code. The application places arguments in registers or memory according to the platform calling convention, executes a special CPU instruction, and transfers control into the kernel. The CPU switches privilege level, the kernel validates the request, performs the operation, and returns a result or error.

; x86-64 Linux: write(1, msg, len); exit(0)

mov rax, 1 ; SYS_write

mov rdi, 1 ; fd = stdout

mov rsi, msg

mov rdx, len

syscall

mov rax, 60 ; SYS_exit

xor rdi, rdi

syscall

Most application code does not issue raw system calls directly. It uses language runtimes, standard libraries, or OS APIs. In C on Linux, functions like open(), read(), write(), and mmap() are usually libc wrappers over system calls. The wrapper is ordinary userspace code; the kernel transition is the privileged part.

The system call boundary is expensive compared to a normal function call because it changes privilege level, touches CPU state, may validate memory, and can block. That cost is one reason why operating systems use buffering, batching, asynchronous I/O, page cache, memory mapping, and other mechanisms to avoid crossing the boundary more than necessary.

7. Scheduling: deciding who runs next

A machine may have many runnable threads and fewer CPU cores than runnable threads. The operating system must choose which thread runs now. That decision is scheduling.

A scheduler maintains queues or trees of runnable tasks, applies policy, and performs context switches when the running task blocks, exits, yields, exhausts its time slice, or is preempted by a higher-priority task.

A context switch saves the current execution state and restores another task’s state. At minimum, this includes CPU registers and scheduling metadata. Depending on the switch, it may also involve changing address spaces, updating memory-management state, and affecting CPU caches and TLBs. Context switching is necessary for multitasking, but it is not free.

stateDiagram-v2

[*] --> Ready

Ready --> Running: scheduler selects task

Running --> Ready: preempted or timeslice expires

Running --> Blocked: waits for I/O, lock, timer, or event

Blocked --> Ready: event completes

Running --> [*]: exits

A general-purpose scheduler tries to balance throughput, fairness, latency, and power. A real-time scheduler prioritizes timing constraints. These goals conflict. A fair scheduler may not meet a deadline. A strict real-time task may starve ordinary work if misconfigured.

Scheduling policy or designSelection ruleWhere it fitsPitfall
Completely Fair Scheduler concept	Track virtual runtime and favor tasks that received less CPU time	General desktop/server fairness	Fairness is not a hard deadline guarantee
EEVDF-style fair scheduling	Use eligible virtual deadlines to improve latency behavior	Modern fair scheduling research and Linux evolution	“Deadline” in the name does not imply hard real-time semantics
`SCHED_FIFO`	Highest-priority runnable task runs until it blocks, yields, or is preempted by a higher-priority task	Real-time workloads needing strict priority	A buggy task can monopolize CPU
`SCHED_RR`	Similar to FIFO, but equal-priority tasks rotate	Real-time workloads with controlled sharing	Still requires careful priority design
`SCHED_DEADLINE`	Uses runtime, period, and deadline parameters	Deadline-driven workloads	Incorrect parameters can destabilize scheduling behavior

Scheduling is resource allocation under time pressure. The scheduler does not merely decide what is efficient. It decides what is allowed to make progress.

8. Concurrency: independent progress with shared consequences

Concurrency means multiple activities are in progress over overlapping time intervals. They may run on different cores simultaneously, or they may interleave on a single core. Either way, their ordering matters.

A text editor demonstrates this immediately. One thread may handle the UI. Another may perform syntax analysis. Another may write autosave data. Another may read from a language server or network source. If these threads share state without coordination, correctness depends on accidental timing.

The basic problem is a race condition: program behavior depends on an uncontrolled interleaving of operations. The result may be correct most of the time and fail under load, on another CPU, or after a minor compiler/runtime change.

Operating systems and runtimes provide synchronization primitives to control this.

PrimitiveDefinitionGood useCommon mistake
Mutex	Mutual exclusion lock with ownership	Protecting shared data	Holding it across slow I/O or unknown callbacks
Spinlock	Lock that waits by spinning instead of sleeping	Very short critical sections, often kernel/low-level contexts	Using it around work that can sleep or take long
Semaphore	Counter-based synchronization primitive	Controlling access to a limited resource pool	Using it where ownership semantics are required
Condition variable	Wait until a predicate becomes true	Producer/consumer coordination	Waiting without checking the predicate in a loop
Barrier	Wait until several participants reach a point	Phase-based parallel algorithms	Using it when participant count is dynamic or uncertain
Completion/event	One task signals that an operation has completed	Kernel and async completion paths	Treating it as a mutual-exclusion lock

A correct condition-variable pattern checks the predicate while holding the mutex and waits in a loop:

pthread_mutex_lock(&m);

while (!ready) {

pthread_cond_wait(&cv, &m);

}

consume(shared_state);

pthread_mutex_unlock(&m);

The loop matters because wakeups can be spurious, and because another thread may consume the condition before the woken thread runs.

9. Deadlock and priority inversion

A deadlock occurs when a set of tasks cannot make progress because each is waiting for another task in the same set. The classic Coffman conditions are:

Mutual exclusion
Hold and wait
No preemption
Circular wait

If all four hold simultaneously, deadlock is possible. Break any one condition, and that specific class of deadlock is prevented.

A common engineering technique is global lock ordering. If every path acquires locks in the same order, circular wait is removed.

A related scheduling failure is priority inversion. A high-priority task waits for a lock held by a low-priority task, while medium-priority tasks keep preempting the low-priority lock holder. The high-priority task is indirectly blocked by lower-priority work.

One mitigation is priority inheritance, where the low-priority lock holder temporarily inherits the higher priority of the blocked waiter. This does not make concurrency simple, but it bounds a major class of priority inversion problems in real-time systems.

10. IPC: communication across process boundaries

Processes are isolated, but useful systems require cooperation. Inter-process communication provides controlled channels for data transfer and coordination between processes.


IPC mechanism	Mental model	Strength	Common pitfall
Pipe	Unidirectional byte stream	Simple, composable, used heavily by shells	No inherent message boundaries
Unix domain socket	Local socket endpoint	Rich local IPC; can pass file descriptors	Pathname sockets must be managed as filesystem objects
Shared memory	Multiple processes map the same memory region	Very low copy overhead	Requires separate synchronization
Message queue	Kernel-managed message transport	Preserves message boundaries	Poor fit for bulk data if shared memory is better
Signal	Asynchronous notification	Good for out-of-band events	Limited structured payload
Memory-mapped file	File contents mapped into address space	Efficient file sharing and lazy loading	Durability semantics can be misunderstood

IPC is not one mechanism. It is a family of trade-offs around copying, synchronization, ordering, backpressure, security, and failure behavior.

A pipe is excellent for streaming bytes from one process to another. Shared memory is better when large data should not be copied. A Unix domain socket is better when endpoints need bidirectional communication, credential passing, or descriptor passing. Signals are appropriate for notification, not structured data transport.

11. Virtual memory: the address-space

Virtual memory is one of the operating system’s central abstractions. Each process appears to have its own private, contiguous address space. In reality, those virtual addresses are translated into physical memory frames through hardware-supported page tables controlled by the kernel.

This design gives the operating system several powers:

isolate one process from another;
map the same physical page into multiple address spaces;
lazily allocate memory on first use;
implement copy-on-write;
map files into memory;
move inactive pages to secondary storage;
protect pages as read-only, executable, or inaccessible.

The CPU issues virtual addresses. The memory-management unit, or MMU, translates them using page tables. If the translation is valid and permitted, the access continues. If not, the CPU raises a page fault, and the kernel decides whether the fault can be handled.

A page fault is not always an error. It may be the mechanism by which memory is allocated, a file-backed page is loaded, or a copy-on-write page is duplicated. It becomes an application-visible failure only when the access is invalid or violates permissions.

12. Paging, segmentation, and address translation

Paging divides virtual and physical memory into fixed-size units called pages and frames. Modern operating systems rely heavily on paging because fixed-size translation composes well with protection, sparse address spaces, demand loading, sharing, and page replacement.

Segmentation is an older memory-management model that divides address spaces into variable-sized logical regions, usually addressed by segment plus offset. It was historically important and still exists in certain architecture-specific forms, but mainstream 64-bit operating systems primarily use paging for general virtual memory.


Memory mechanism	Definition	Why it exists	Pitfall
Paging	Fixed-size virtual pages mapped to physical frames	Isolation, demand allocation, sharing, swapping	Assuming virtual contiguity implies physical contiguity
Segmentation	Variable-sized logical memory regions	Historical logical separation and specialized architecture use	Teaching it as the dominant modern mechanism
Page table	Data structure mapping virtual pages to physical frames	Hardware-assisted address translation	Ignoring page-table memory overhead
TLB	CPU cache for address translations	Avoid repeated page-table walks	Forgetting that address-space switches can affect TLB behavior
Page fault	Trap caused by missing or invalid translation	Lazy allocation, demand paging, protection	Treating every page fault as a crash
Copy-on-write	Shared page copied only when written	Efficient fork and memory sharing	Unexpected write amplification under mutation

Virtual memory is not only about “using disk as extra RAM.” That is a narrow and often outdated description. The deeper point is controlled address translation. Once every memory access goes through an enforceable mapping layer, the operating system can isolate, share, revoke, lazily create, and account for memory.

13. Caching and the working set

A cache stores data closer to the consumer than its original source. Operating systems cache aggressively because storage and memory hierarchies are slow relative to CPU execution.

Important OS-level caches include:

CPU cache: hardware-managed cache for memory access.
Translation lookaside buffer: CPU cache for virtual-to-physical translations.
Page cache: kernel cache for file-backed pages.
Dentry/inode caches: filesystem metadata caches for path lookup and object identity.
Buffer cache or block cache: storage-oriented cached block data, depending on OS design.

The working set of a process is the set of pages it actively uses over a time window. If the working sets of active processes fit in memory, the system can run efficiently. If they exceed memory, the system may thrash: it spends more time moving pages than executing useful work.

A common mistake is reading “used memory” as bad. On a healthy system, unused memory is often wasted memory. The kernel may use spare memory as page cache and reclaim it when applications need memory. The important distinction is not used versus free. It is reclaimable cache versus unreclaimable pressure, cache hits versus misses, and steady-state behavior versus thrashing.

14. Filesystems: names, metadata, and persistence

A file system gives persistent data a namespace and structure. It maps pathnames to file objects, maintains metadata, controls permissions, and organizes data on storage media.

When a process calls open("/home/user/notes.txt"), the kernel does not simply parse a string and jump to disk. It performs pathname resolution through directory entries, mount points, permissions, caches, and filesystem-specific operations.

Several concepts matter:

A pathname is a name used to locate a file.
A directory maps names to filesystem objects.
An inode represents file metadata and identity in Unix-like filesystems.
A dentry represents a directory-entry cache object in the kernel.
A mount point attaches one filesystem tree into another.
A file descriptor gives the process a handle to an opened object.

Modern kernels often use a virtual file system, or VFS, to present a common interface over many filesystem implementations. The VFS lets code call generic operations while ext4, XFS, Btrfs, tmpfs, procfs, and other filesystems provide implementation-specific behavior behind the interface.

A file operation therefore crosses several abstraction layers. The user sees bytes and names. The kernel sees descriptors, dentries, inodes, pages, block requests, device queues, and completion events.

15. Journaling and crash consistency

Persistence is not only about writing bytes. It is about recovering after interruption.

A journaling file system records enough information about pending filesystem updates to restore consistency after a crash. Updates can be grouped into transactions. If the system crashes mid-update, the journal can be replayed or rolled back to avoid leaving metadata in an inconsistent state.

The important point is precision: journaling usually protects filesystem metadata consistency, not necessarily every application-level data expectation. A successful write() may copy data into the page cache without forcing it to stable storage. A later fsync() or equivalent durability operation is often required when an application needs stronger guarantees.


Persistence concept	Definition	Why it matters	Common misunderstanding
Page cache write	Data accepted into kernel memory	Allows fast buffered writes	Not necessarily durable yet
Writeback	Kernel flushes dirty pages to storage	Moves cached changes toward persistence	Timing may be delayed
Journal transaction	Metadata update recorded for recovery	Maintains filesystem consistency	Does not automatically guarantee application-level durability
`fsync`	Request to flush file data/metadata as required	Used for durability boundaries	Can be expensive and still hardware-dependent
Atomic rename	Replace name binding atomically	Common safe-update pattern	Does not replace proper flush ordering

For applications such as databases, editors, package managers, and configuration systems, crash consistency is a design requirement. The operating system gives primitives. Correct durability requires using them with the right ordering.

16. I/O, device drivers, interrupts, and DMA

Input/output is where software meets devices. A device driver is kernel-side code that controls a hardware or virtual device and exposes it through OS abstractions.

Storage, network cards, GPUs, keyboards, timers, and sensors all differ internally. The kernel hides much of that complexity by routing requests through driver frameworks and subsystem interfaces. A block storage request, for example, may pass through a filesystem, page cache, block layer, I/O scheduler, driver, controller, and device firmware.

The device must eventually notify the CPU that something happened. That notification is often an interrupt. An interrupt causes the CPU to stop its current flow, enter a privileged handler, and execute kernel code associated with the event.

Interrupt handlers must be careful. They run in sensitive contexts and should usually do minimal work: acknowledge the device, collect essential status, and defer heavier processing to safer kernel contexts.

Many high-performance devices also use direct memory access, or DMA. DMA lets a device transfer data directly to or from memory without the CPU copying every byte. The CPU configures the operation, the device performs the transfer, and an interrupt or polling path reports completion.

Efficient I/O is therefore not only about device speed. It is about avoiding copies, batching requests, minimizing context switches, controlling queue depth, handling completion efficiently, and preserving correctness under failure.

17. Security, permissions, and capabilities

An operating system cannot only multiplex resources. It must also enforce who can use them.

Traditional Unix-like systems use users, groups, and permission bits. A process has credentials. Files have ownership and access modes. The kernel checks whether the process may read, write, or execute an object. This is discretionary access control, because object owners can often decide access rules.

Modern systems add more layers:

Capabilities split privileged powers into finer-grained units.
Access-control lists provide richer per-object permissions.
Mandatory access control systems such as SELinux or AppArmor impose policy beyond ordinary owner discretion.
Sandboxing limits what a process can see or do.
Integrity mechanisms verify that data or code has not been modified unexpectedly.

The security model is not one feature. It is the combination of identity, authorization, object labeling, isolation, auditability, and least privilege.

A key distinction: visibility isolation is not the same as permission enforcement. A namespace may hide resources from a process, but hiding is not a complete security policy by itself. Robust isolation combines namespaces, permissions, capabilities, seccomp-style syscall filtering, MAC policy, and careful runtime configuration.

18. Containers: isolating process trees

A container is not a small virtual machine in the strict technical sense. A container is an isolated process environment that shares the host kernel.

Most Linux container systems are built from two major kernel facilities:

Namespaces isolate views of system resources.
cgroups account for and limit resource usage.

Namespaces can isolate process IDs, mount points, network interfaces, hostnames, users, IPC objects, and time views. Cgroups can organize processes hierarchically and control CPU, memory, I/O, and other resource consumption.

Isolation mechanism What it controls Example effect
PID namespace	Process ID view	A container can have its own PID 1
Mount namespace	Filesystem mount view	A container sees its own root filesystem
Network namespace	Network stack view	A container can have its own interfaces and routing table
User namespace	User and group ID mappings	Root inside the container need not be root outside
IPC namespace	IPC object visibility	Shared memory and message queues can be isolated
UTS namespace	Hostname/domain name view	A container can have its own hostname
cgroup	Resource accounting and limits	CPU and memory usage can be constrained

A container runtime assembles these mechanisms into a usable execution environment. It prepares filesystems, sets resource limits, configures namespaces, applies security policy, and starts the container process.

The practical difference from a virtual machine is clear: a container isolates a process tree using one shared kernel; a virtual machine runs a guest operating system on virtualized hardware.

19. Virtual machines and hypervisors

A virtual machine presents an entire virtual computer to a guest operating system. The guest kernel believes it controls CPUs, memory, devices, and interrupts. In reality, a hypervisor mediates access to the underlying hardware.

Virtualization can be implemented in different styles:


Virtualization model	Description	Typical use
Type 1 hypervisor	Runs directly on hardware	Cloud, enterprise virtualization, bare-metal platforms
Type 2 hypervisor	Runs on a host OS	Desktop virtualization and development
Hardware-assisted virtualization	CPU provides virtualization extensions	Modern mainstream VM performance
Paravirtualization	Guest cooperates with hypervisor-aware interfaces	Efficient I/O and reduced emulation overhead
Nested virtualization	A VM runs another hypervisor	Cloud testing, virtualization development

VMs provide stronger kernel-level isolation than containers because each VM can run its own guest kernel. This also means more overhead: memory for the guest OS, virtual devices, emulation or paravirtual interfaces, and additional scheduling layers.

Containers and VMs are often used together. A cloud workload may run containers inside a VM. The VM provides tenant isolation; the container provides application packaging and process-level isolation.

20. Resource allocation: fairness is not isolation

The operating system must allocate CPU time, memory, I/O bandwidth, network capacity, and device access among competing workloads. Isolation prevents workloads from seeing or corrupting each other. Resource allocation prevents one workload from consuming everything.

These are related but distinct. A container may have a separate filesystem view but still consume too much CPU. A process may have restricted permissions but still allocate enough memory to pressure the system. A real-time task may be authorized but still starve normal tasks.

Resource allocation uses several mechanisms:

scheduler policy and priority;
CPU affinity and quotas;
memory limits and reclaim behavior;
I/O scheduling and throttling;
network shaping;
cgroup accounting;
admission control for real-time workloads.

A good system is not merely secure. It is predictable under contention.

21. Kernel data structures

Operating systems are data-structure-heavy programs. Kernel behavior is shaped by how it tracks tasks, memory ranges, open files, cached names, timers, sockets, and devices.

Common kernel data structures include:


Data structure	Typical OS use	Why it fits
Linked list	Task lists, wait queues, simple collections	Cheap insertion/removal when traversal is acceptable
Red-black tree	Scheduling timelines, ordered mappings	Maintains ordered data with logarithmic operations
Radix tree / XArray	Page cache and indexed kernel objects	Efficient sparse index lookup
Hash table	File caches, networking tables, object lookup	Fast average lookup by key
Bitmap	Resource allocation maps	Compact representation of free/used units
Ring buffer	Tracing, logging, network queues	Efficient producer/consumer buffering
Queue	I/O requests, work scheduling	Natural ordering of pending work

This matters because OS performance is often dominated by lookup paths and contention points. The difference between a list, tree, bitmap, and hash table can become visible at scale.

22. Performance tuning and observability

Performance tuning without measurement is guesswork. Operating systems expose observability tools because the real source of latency or throughput loss is often not where the application developer first expects.

Common dimensions include:

CPU utilization and run queue length;
context-switch rate;
page faults and memory pressure;
cache hit/miss behavior;
block I/O latency and queue depth;
network retransmits and socket buffers;
lock contention;
interrupt rate;
scheduler latency;
syscall frequency;
filesystem writeback behavior.

Tools differ by operating system, but the measurement principle is stable. On Linux, examples include perf, strace, ftrace, bpftrace, vmstat, iostat, pidstat, top, htop, ss, and /proc//sys inspection.

A practical investigation flow is:

Define the symptom: latency, throughput, CPU, memory, I/O, or correctness.
Measure the boundary: application, syscall, kernel, device, network, or storage.
Identify whether time is spent running, waiting, blocked, or retrying.
Change one variable.
Measure again.

The operating system is full of knobs, but most knobs are workload-specific. Scheduler tuning, dirty page ratios, huge pages, I/O schedulers, CPU affinity, cgroup limits, and network buffers can improve one workload and damage another.

23. Real-time operating system concepts

A real-time operating system is designed around timing correctness. The key question is not “is it fast?” but “can it respond within a required bound?”

Real-time work is often divided into:


Category	Meaning	Example
Hard real time	Missing the deadline is system failure	Airbag control, certain industrial safety loops
Firm real time	Late result has no value, but failure is not catastrophic	Some media or telemetry frames
Soft real time	Late result degrades quality	Audio, video, interactive systems

Real-time systems care about worst-case latency, interrupt handling, preemption points, priority inversion, lock hold times, scheduling policy, and bounded resource use. A low average latency is not enough if the worst-case tail is unbounded.

General-purpose operating systems can support real-time features, but they are not automatically real-time systems. A real-time configuration must control the full path: hardware interrupts, kernel preemption, scheduler policy, driver behavior, memory allocation, page faults, locks, and user-space design.

24. The complete path: opening, editing, and saving a file

Now combine the mechanisms.

You press the power button. Firmware initializes hardware and loads a bootloader. The bootloader loads the kernel and initial filesystem. The kernel initializes memory management, interrupt handling, scheduler state, device drivers, and core subsystems. PID 1 starts services and the user session.

You launch an editor. The system creates a process, loads executable segments, maps libraries, prepares a stack and heap, creates or inherits file descriptors, and places the initial thread on a run queue.

The editor opens a file. A library wrapper calls into the kernel through a system call. The kernel checks credentials, resolves the pathname through the VFS, uses dentry and inode caches if possible, and returns a file descriptor.

The editor reads data. The kernel checks the page cache. On a cache hit, data can be copied or mapped quickly. On a cache miss, the filesystem and block layer submit I/O to a driver. The device transfers data, possibly using DMA, and reports completion through an interrupt or polling path. The kernel wakes the blocked thread.

The editor renders text while background threads parse, index, and autosave. The scheduler moves threads between running, ready, and blocked states. Locks protect shared data. Condition variables or completions coordinate ordered work. Bad lock ordering can deadlock. Bad priority design can invert scheduling priorities.

The process allocates memory. The allocator requests address space or pages. The MMU translates virtual addresses. Missing mappings trigger page faults. Valid faults allocate or load pages. Invalid faults terminate the process or raise a signal.

You save the file. The kernel writes data into the page cache, marks pages dirty, updates metadata, and later writes changes to storage. A journaling filesystem records metadata transactions so the filesystem can recover after a crash. If the application requires durability, it must use the correct flush operations and ordering.

The editor may run inside a container. Namespaces define what it can see. Cgroups define what it can consume. Capabilities and security policy define what it can do. The container may itself run inside a VM, where a hypervisor presents virtual hardware to a guest kernel.

The system remains useful only if performance is measured and controlled. The scheduler must distribute CPU time. The memory manager must avoid pathological reclaim. The I/O stack must avoid unnecessary latency. Real-time workloads must bound tail latency, not merely improve average throughput.

This is the operating system: a sequence of controlled translations. Power becomes execution. Executables become processes. File names become kernel objects. Virtual addresses become physical frames. Writes become durable media updates. Hardware events become scheduled software work. Physical resources become enforceable abstractions.

25. Core Concepts


Concept	One-line definition	Where it appears in the story	Pitfall to remember
Operating system	Software layer that manages hardware and provides abstractions	Entire article	Treating it as only a UI or only a kernel
Kernel	Privileged core of the OS	Boot and system-call sections	Forgetting that kernel bugs affect the whole system
Firmware	Low-level software that initializes hardware	Power-on path	Confusing firmware with the OS
Bootloader	Program that loads the kernel	Boot path	Assuming the OS starts first
Process	Running program instance with execution state	Application launch	Confusing process with thread
Thread	Schedulable execution stream inside a process	UI and worker execution	Ignoring shared-memory races
System call	Controlled entry into kernel services	File open/read/write	Treating it like a normal function call
File descriptor	Per-process handle to kernel I/O object	File and socket access	Leaking descriptors across exec
Scheduling	Choosing which runnable task executes	Multitasking	Equating fairness with deadlines
Context switch	Save one execution state and restore another	Task transitions	Ignoring cache/TLB effects
Concurrency	Independent activities with interleavings	UI, worker, autosave	Assuming rare interleavings are impossible
Synchronization	Coordination of shared state or event order	Locks and waits	Choosing primitives by habit instead of context
Deadlock	Tasks wait forever in a cycle	Lock ordering	Breaking none of the Coffman conditions
Priority inversion	High-priority work blocked indirectly by lower-priority work	Real-time scheduling	Ignoring lock holder priority
IPC	Communication between processes	Pipes, sockets, shared memory	Using one IPC style for every workload
Virtual memory	Per-process virtual address abstraction	Pointer access and mapping	Assuming virtual equals physical
Paging	Fixed-size virtual-to-physical mapping	Page-table translation	Ignoring page-fault and TLB costs
Segmentation	Variable logical memory regions	Architecture history	Overstating its modern general use
Page fault	Trap on missing or invalid translation	Demand allocation	Treating every fault as an error
Page cache	Kernel cache for file-backed pages	File read/write	Calling cached memory wasted memory
Filesystem	Persistent namespace and metadata layer	Open/save path	Treating path lookup as string parsing only
Inode	Filesystem metadata object	File identity	Confusing file name with file object
VFS	Generic filesystem abstraction layer	Filesystem dispatch	Forgetting that different filesystems implement different semantics
Journaling	Transaction-style recovery mechanism	Crash consistency	Assuming it guarantees all application data durability
Device driver	Kernel code controlling a device	I/O path	Treating driver code like ordinary app code
Interrupt	Hardware or software event that redirects execution	I/O completion	Doing too much work in interrupt context
DMA	Device transfers data directly to/from memory	High-performance I/O	Ignoring memory mapping and synchronization requirements
Permissions	Rules controlling access to objects	File open and execution	Assuming visibility equals authorization
Capability	Fine-grained authority model	Privilege control	Running everything with broad privilege
Namespace	Isolated view of a system resource	Containers	Treating namespaces as a complete security model
Cgroup	Resource accounting and control group	Containers and resource limits	Confusing isolation with fairness
Container	Isolated process environment sharing host kernel	Deployment	Calling it a VM without qualification
Virtual machine	Emulated or virtualized hardware environment for a guest OS	Cloud and nested isolation	Confusing VM isolation with container isolation
Hypervisor	Software layer managing virtual machines	VM execution	Ignoring overhead and device virtualization
Real-time OS	OS designed around bounded timing behavior	Latency-critical workloads	Optimizing average latency while ignoring worst case
Performance tuning	Measurement-driven optimization	Final system behavior	Tuning before observing

26. Further reading

For conceptual study:

For implementation-oriented reading:

In a nutshell

An operating system is not a single mechanism. It is a set of enforced abstractions arranged around hardware constraints. The kernel virtualizes resources, schedules execution, isolates memory, mediates access, coordinates concurrency, caches aggressively, persists data carefully, and reacts to hardware events under strict timing and correctness constraints.

The simple act of launching an editor and saving a file crosses nearly every major OS concept: boot, process creation, threads, system calls, scheduling, synchronization, virtual memory, filesystems, I/O, device drivers, interrupts, permissions, caching, journaling, containers, virtual machines, and performance measurement.

That is why operating systems remain one of the most important subjects in computer science. They define the contract between software and hardware, and they decide how safely, fairly, and efficiently every program gets to exist.