Operating systems,
from the ground up.

Why the kernel matters.

Three problems, repeated forever. Sharing: many programs, one set of CPUs, one slab of RAM, one disk. The OS multiplexes both across time and space. Isolation: each program must believe it owns the machine, and one program's bug must not corrupt another. Abstraction: programs should not have to know whether the disk is a platter, an SSD, or a network filesystem. The file descriptor is the unifying layer.

Unix solved all three with a small set of primitives — process, file, fork, exec, the stream of bytes. Fifty-three years later the same primitives run hyperscale clouds. Linux added namespaces and cgroups for stronger isolation; io_uring and eBPF for cheaper abstraction; PREEMPT_RT for harder real-time. The shape stayed.

Read the kernel, you'll think differently about your code. Most of what you can change in user-space looks small once you've seen what the kernel does on every syscall. Profilers stop being mysterious. Latency budgets stop being arbitrary. "the OS is slow" becomes "I am holding the OS wrong".

Twelve mental models.

Twelve concepts cover ~95% of OS surface. Get these in your bones in the first month. Every kernel feature you meet (containers, eBPF, io_uring, KVM) is a recombination of them.

Day zero — first hour.

One hour. Read OSTEP chapters 4 (the abstraction: process), 13 (address spaces), and 26 (concurrency, an introduction). Then strace a simple program, watch every syscall, and follow one major page fault. The bar is muscle: read the right OSTEP chapters, then watch the kernel react in real time.

# 1. Read OSTEP ch. 4, 13, 26 (≈ 60 minutes)
#    https://pages.cs.wisc.edu/~remzi/OSTEP/

# 2. Pick a tiny C program (or write one)
cat > hello.c <<'EOF'
#include <stdio.h>
#include <unistd.h>
int main(void) { printf("hi from pid %d\n", getpid()); sleep(1); return 0; }
EOF
cc hello.c -o hello

# 3. Watch every syscall
strace -e trace=execve,openat,mmap,brk,write,exit_group ./hello

# 4. Watch page faults on a heavier program
/usr/bin/time -v ./your-actual-program 2>&1 | grep -E 'page faults|context switches'

# 5. Read your own /proc — pick a long-running process (e.g. your shell)
cat /proc/$$/status     # state, threads, RSS, VSZ
cat /proc/$$/maps       # virtual address layout
cat /proc/$$/limits     # rlimits

# 6. Trace a system-wide event for 30s with bpftrace (optional)
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat
  { printf("%s -> %s\n", comm, str(args->filename)); }'

Done. You have read the right three chapters, watched a real syscall trace, inspected /proc, and (optionally) used eBPF to watch the system in flight. Everything below builds from here.

Week 1 to Month 3 — pick a track.

After the first hour you can read OS writing without bouncing off it. Spend the next three months on one track at a time, depth-first. Don't try to learn schedulers and file systems in the same fortnight. Pick the one that maps to your job and finish it.

Books worth reading.

Honourable mentions: Understanding the Linux Kernel (Bovet, Cesati — older but still excellent on the VM subsystem); Linux System Programming (Robert Love — the user-space companion to LKD); The Design of the UNIX Operating System (Bach — historical but still beautifully clear on the original architecture).

Courses and references.

• MIT · 6.S081 (formerly 6.828)
  Operating System Engineering
  The MIT undergrad OS course. Build xv6 — a teaching Unix derivative — over the semester. The single best self-study path in OS. Free lectures, slides, labs, and an unforgettable rite of passage.
• Wisconsin · OSTEP
  Operating Systems: Three Easy Pieces
  Arpaci-Dusseau’s textbook + course. Free PDF online; xv6 labs; the cheerful tone that makes systems concepts approachable without sacrificing rigour. The right modern OS textbook.
• kernel.org
  The Linux Kernel Documentation
  The official tree-of-docs. admin-guide for sysctls and tunables; scheduler/ for CFS / EEVDF design; mm/ for memory management; networking/ for the stack. The first stop when "what does this kernel knob do?".
• LWN.net
  Kernel Index
  Every major kernel feature, narrated by Jonathan Corbet and team. Read 5–10 articles a week and you will know the kernel’s direction better than most full-time contributors. Subscribe.
• Brendan Gregg
  Performance writing & flame-graph methodology
  Gregg’s site is a self-contained postgrad in Linux performance — flame graphs, USE method, BCC tools, eBPF. Pair with his Systems Performance and BPF Performance Tools books for the full course.
• Michael Kerrisk · man7.org
  Linux man-pages, online
  Kerrisk’s authoritative collection. man7.org/linux/man-pages/man2/syscall.2.html is the single best one-page intro to syscalls. The man-pages are technically the spec; treat them as such.

• Bradfield CS
  Computer Architecture & Operating Systems
  Cohort-based, instructor-led; pricey. The OS chunk pairs with Bradfield’s networking and DB courses for the full systems education. Watch first; pay if the structure helps you.

Papers worth reading.

Twelve papers, roughly 1965 → 2019. Read them in order. The field is dense and citation- heavy. Most are 10–25 pages.

1. 01
   1965 · Dennis & Van Horn

   Programming Semantics for Multiprogrammed Computations

   The paper that gave us the process abstraction. Read it for the historical frame: "what is a process" was a research question once. Twenty pages.

2. 02
   1973 · Lampson

   A Note on the Confinement Problem

   Lampson's covert-channel paper. The first formal treatment of "what does the OS keep secret, and from whom". The vocabulary of seven covert-channel categories is still the right one in 2026.

3. 03
   1974 · Ritchie & Thompson

   The UNIX Time-Sharing System

   The Bell Labs CACM paper. Twelve pages explaining files, processes, the shell, the directory tree, pipes. Every Unix design decision in the field traces back to this; read it before any other OS paper.

4. 04
   1992 · Rosenblum & Ousterhout

   The Design and Implementation of a Log-Structured File System

   LFS — write the entire disk as a circular log. The architectural ancestor of every modern flash-aware filesystem (F2FS, the FTL inside SSDs themselves). Read it for the disk-as-log mental model.

5. 05
   1995 · Bonwick

   The Slab Allocator: An Object-Caching Kernel Memory Allocator

   Bonwick's slab allocator from Solaris. The Linux SLUB allocator descends directly. Read for the "object pools matter" insight that drives every kernel memory allocator since.

6. 06
   1996 · Cao, Felten, Karlin, Li

   Implementation and Performance of Application-Controlled File Caching

   The classic paper on letting applications hint at the page cache. madvise, posix_fadvise — they all trace here. Read before tuning vm.* anywhere in production.

7. 07
   2004 · Bershad et al

   Lightweight Recoverable Virtual Memory

   The mmap-and-checkpoint pattern. The intellectual ancestor of every modern persistent-memory and copy-on-write database. Worth reading before reaching for kernel byte-addressable persistent memory APIs.

8. 08
   2010 · McKenney

   Memory Barriers: A Hardware View for Software Hackers

   McKenney is the author of RCU. This paper explains memory barriers, store buffers, and cache coherence from the hardware side. Read it once and the C++/Rust acquire/release vocabulary stops being mysterious.

9. 09
   2014 · Anderson, Dahlin

   Operating Systems: Principles & Practice (the OS:PP textbook)

   Not a paper, but the text. Modern OS textbook from Tom Anderson; pairs with OSTEP. Particularly strong on synchronisation and threads. Free PDF chapters online.

10. 10
    2017 · Bonifaci, Brandenburg, Stiller, Wieder

    Counting on Fast Userspace Mutexes (futex revisited)

    A revisit of futex semantics with priority inheritance. If you operate latency-critical code, this is required reading; if you don't, it's a beautiful narrow paper to feel smart about.

11. 11
    2019 · Axboe et al

    io_uring: An Introduction (kernel docs)

    Jens Axboe's introduction to io_uring. Submission and completion rings, polling mode, fixed buffers. The substrate every new high-throughput Linux server in 2020+ is built on.

12. 12
    2020 · Gregg

    BPF Performance Tools

    Brendan Gregg's comprehensive book on eBPF for production observability. opensnoop, execsnoop, tcpconnect, profile — every diagnostic tool reduced to a one-liner. Pair with his earlier Systems Performance book.

Going further: Lampson’s "Hints for Computer System Design"; the Mach paper (Accetta et al, 1986); the seL4 verification paper (Klein et al, 2009); the Singularity OS papers from MSR; Solaris’ DTrace (Cantrill, 2004) — the conceptual ancestor of eBPF.

Talks worth watching.

• Brendan Gregg · USENIX
  Linux Performance Analysis in 60 seconds
  The legendary checklist talk. uptime, dmesg, vmstat, mpstat, pidstat, iostat, free, sar, top, in 60 seconds. Watch it; tape the slide on your monitor.
• Liz Rice · KubeCon
  Containers from Scratch
  Live-coded container runtime in Go in 30 minutes. unshare, clone, pivot_root, cgroups. The talk that turns "containers are magic" into "containers are five Linux features stacked".
• Bryan Cantrill · USENIX LISA
  Debugging under Fire
  Cantrill on production debugging. DTrace, mdb, the post-mortem methodology. Funny, sharp, devastating about industry myths. Every Cantrill talk is worth watching; this one is the canonical one.
• Jens Axboe · ATC 2019
  io_uring: a new I/O subsystem for Linux
  The author’s introduction. Submission/completion rings, the kernel-side polling mode, fixed buffers. Watch this before reaching for liburing.
• Brendan Gregg · LISA
  Linux Profiling at Netflix Scale
  eBPF tools, flame graphs, USE method, on-CPU vs off-CPU. The Netflix-scale story is illustrative; the methodology applies to any production Linux box.

Hands-on tools.

Theory without something you can run is fragile. Each of these is a manageable way to make the kernel push back when you make a mistake.

Latency, at a glance.

Twelve numbers, calibrated for modern hardware. Print this and tape it next to the monitor. The ones that surprise people most: a syscall costs ~10× a function call, an L2 miss costs ~100× an L1 hit, and a major page fault costs ~10,000× a minor one.

Numbers are order-of-magnitude on a 2024-class x86 server. Always measure on your own hardware. Jeff Dean’s "Latency Numbers Every Programmer Should Know" — last updated by colinscott — is the canonical scaffold.

Common mistakes.

Patterns every team writes at least once. Read these now and you'll recognise the shape later, when something on-call is misbehaving and the dashboard is no help.

Forgetting that fork() is COW

A 4 GB process forks; the engineer thinks "we just doubled RAM". No — the child shares pages until it writes. Fork is microseconds. The actual mistake is calling exec() too late, holding lots of dirty pages.

Treating threads as free

A thread is 8 MB of virtual address space, ~16 KB of kernel state, plus context-switch cost. 100k threads on Linux works (it's designed for it), but unbounded thread pools deadlock under load. Cap the pool; queue the rest.

Blocking the runtime's event loop

A synchronous read inside an async runtime (Node, Tokio, Go without proper isolation) can stall the whole event loop. Either move the work to a worker pool or use the runtime's blocking-syscall offload.

Ignoring CFS throttling

Kubernetes CPU limits are enforced by cgroup CFS bandwidth control. A burst hits the quota; the cgroup is frozen for the rest of the period (default 100 ms). Symptoms: tail-latency spikes correlated with the period. Fix: raise the limit, remove it, or use SCHED_DEADLINE.

fsync paranoia (or lack thereof)

A successful write() puts bytes in the page cache, not on disk. fsync flushes them. fsync on the parent directory after rename is required for the rename to survive a crash. Most "we lost data after a power cut" bugs trace here.

Misusing /dev/urandom vs getrandom

Old code reads /dev/random and blocks at boot waiting for entropy. Modern code calls getrandom(2) (default flags) — it does the right thing on every kernel since 3.17. Don't ship blocking entropy reads in 2026.

Storing config in env without size limits

execve has a hard limit on argv+envp size (~128 KB on Linux). Container orchestrators happily inject 200 KB of env vars, and your fork/exec starts failing with E2BIG. Cap env-var sizes in the config layer.

Treating mmap as faster I/O

mmap looks like memory; underneath it's page faults that issue disk I/O. For sequential reads of large files, read() with a sane buffer is often faster (no fault-per-page overhead). Profile.

Writing to /tmp without considering tmpfs

/tmp is RAM-backed (tmpfs) on most distros now. A 50 GB write to /tmp can OOM the box. Use /var/tmp or an explicit on-disk path for large temp files.

Reaching for a thread when a process would be safer

A bug in a thread takes down its siblings; a bug in a process takes down only itself. For untrusted code, hot-reload, or "I want a hard isolation boundary", processes are the right tool — even at their higher cost.

Quick test.

Ten cards: the questions interviewers ask, the things that bite operators in production, and the trivia that separates "I run Linux" from "I understand it".

Reading progressions

Three ordered paths through this material. Pick the one that matches where you are.

What's next.

Operating systems reward re-reading. OSTEP, read on day 30 and again on day 300, will give you different things. So will Robert Love’s LKD. So will every Brendan Gregg talk. The field is not large. It is dense, and it has been compounding for fifty years.

Pick one real kernel subsystem and read its source for an afternoon. The Linux scheduler (kernel/sched/), the page-cache (mm/filemap.c), the futex implementation (kernel/futex/) are all open. Pair what you read with the paper that inspired it. Then come back to your own code, your own profiles, your own slow paths. You will rewrite some of them.