The OS Simulator: Cores, Processes, RAM, I/O and Locks

The playground is a discrete-time model. Each tick, a simulated scheduler picks runnable threads for each core, charges a context-switch cost when a core changes thread, advances each thread’s work, and decides whether it blocks on I/O, faults on a page or waits for a lock. Memory is a set of pages with an LRU-style replacement policy (LRU Cache); I/O is a queue with a fixed service time; locks are mutexes with a wait queue. The numbers on every panel come from that model. They are chosen to be *realistic in shape* — a context switch costs on the order of a few microseconds, a page fault to a simulated SSD costs on the order of 100 µs, a lock hand-off costs less than a switch — but they are not measurements, and the interactive says so with a Simulated tag.

What is deliberately left out: cache effects, NUMA, interrupt handling, priority inheritance, real scheduler heuristics (CFS/EEVDF weights, Windows priority boosts), write-back, and the difference between minor and major page faults. Those are the reasons a real system’s curve will differ from the simulator’s in slope, never in direction. The goal is to make the *mechanism* visible: if the model shows throughput falling when you add threads, the real system will too — at a different thread count.

Each control models one resource from a lesson in this domain, and each one is a constraint the real kernel juggles.

Two of the controls interact in ways the others do not. Threads and cores together decide the switching regime — throughput rises with threads until threads equal cores and falls after — and RAM and processes together decide the working set, because every process brings its own pages. Set one control at a time when you are learning a mechanism; set two together when you are learning why production incidents rarely have one cause.

The scheduler panel shows each core and which thread it is running, with the ready queue beside it (Queue → ready queue is the DSA transfer). A long ready queue with busy cores is CPU saturation; an empty queue with idle cores and many blocked threads is I/O-bound. The context switches counter and the switch overhead % show what fraction of each core’s time was spent saving and restoring state rather than doing work (Context Switching) — when it passes a few percent, adding threads is now costing throughput.

The memory panel shows frames in use, the simulated working set, and page faults per tick. Faults near zero mean the working set fits; a fault rate that jumps when RAM drops below the working set is the thrashing knee (Page Faults, Memory Pressure, Swap and the OOM Killer) — the same shape as a real system where vmstat starts showing si/so and %wa. The blocked panel lists threads waiting on I/O or a lock and how long they have waited; the lock contention panel shows, per lock, its wait-queue length and the fraction of time it is held. A lock held 90% of the time with a queue of seven is a serial section — Amdahl’s law made visible.

1. Add threads until context switching dominates. Set 4 cores, 1 process, 4 threads, ample RAM, no I/O, no locks. Throughput should be near the maximum. Now raise threads to 8, 16, 64, 256. Predict first: throughput cannot rise beyond 4 cores’ worth; what will it do? Watch the switch overhead % climb and throughput bend downward as more of each slice is spent switching. Then shorten the time slice and watch the knee move left. The real-world version is a thread-per-connection server (Thread per Connection) at 10,000 connections, or a Node worker pool sized at os.cpus().length * 8.

2. Shrink RAM until page faults explode. Set 2 cores, 4 processes, RAM comfortably above the combined working set. Faults should be near zero after warm-up. Now shrink RAM in steps. Predict the knee: at what fraction of the working set does the fault rate leave zero? Observe that it is not gradual — LRU replacement keeps up until the working set no longer fits, then every access evicts something needed soon. Throughput falls off a cliff while cores show as busy-waiting on faults. That is the swap storm of memory-pressure-swap-storm, and why “add RAM” fixes some slow systems and does nothing for others.

3. Add one lock and watch contention. Set 8 cores, 8 threads, no I/O. Throughput ≈ 8×. Add one lock that each thread takes for 10% of its work. Predict: does throughput stay at 8×, drop to 1×, or land between? Watch the lock’s hold fraction approach 80% and the queue grow; throughput settles far below 8× because the 10% serial section caps the speed-up (Amdahl: 1/(0.1 + 0.9/8) ≈ 4.7×). Raise the locked fraction to 50% and cores go idle waiting. Then split it into two locks and see the queue halve. This is high-cpu-spin-lock and every “we added cores and nothing changed” story.