One click, all eight modules

Aisha presses Ctrl+B to build her project.

Four seconds later matrix exists on disk.

In between, the operating system did every single thing this course has described — interrupts, forking, scheduling, locking, address translation, page faults, disk allocation, DMA — and Aisha noticed none of it.

Here is the whole trace, in order, with the numbers we have been using since Module 1.

Why & what

Why trace it. Modules are a teaching convenience. The machine does not have modules. An interviewer who asks "what happens when you press a key?" is checking whether you can cross those boundaries, and it is the fastest way to tell a memoriser from someone who understands. The first 150 microseconds — before anything is visible.

• 0 µs. The keyboard raises an interrupt. The CPU was running the browser. (Module 1: hardware demanded, so the kernel runs.)
• 25 µs. The handler finishes and moves the editor from Waiting to Ready. (Modules 1 and 2.)
• 30 µs. Context switch to the editor — save one PCB, load another, 5 µs. (Modules 2 and 3.)
• 32 µs. The editor traps into the kernel with fork(). (Modules 1 and 2.)
• 44 µs. The child calls exec("gcc") and becomes PID 2317. (Module 2.)
• 144 µs. First page fault. 100 µs to pull gcc's first code page in from the SSD. (Modules 7 and 6.)

The next three seconds — the compile itself.

• 4 ms. The quantum expires. PID 2317 goes to the back of the ready queue and the browser gets a turn. (Module 3.)
• 120 ms. Opening matrix.c: directory entry → inode 1842 → three 4 KB blocks. (Module 8.)
• 300 ms. The log buffer fills. The producer thread sleeps on wait(empty). (Module 4.)
• 1.2 s. The editor and the compiler both want build.log and matrix. Lock ordering means no circular wait forms. (Module 5.)
• 2.8 s. The working set grows, faults rise, the OS trims somebody's frames. (Module 7.)
• 3.2 s. DMA writes all 350 blocks of matrix and raises one interrupt. (Module 8.)

And underneath all of it, every memory access above went through the MMU, hit or missed the TLB, and had a page number swapped for a frame number with the offset copied unchanged.

Module 6 never appears as an event because it never stops running.

How it works

Telling this story under pressure. Five anchors, in order:

1. Start at the hardware. An interrupt or a trap. There is no third way for the kernel to start running.
2. Get to a process. Which one, in which state, and what moved it.
3. Get it onto a core. The scheduler picked it, the dispatcher switched to it, and that cost something.
4. Let it touch memory and files. Translation, faults, inodes, blocks.
5. End at the device. DMA, one interrupt, done.

Interrupt → process → scheduler → memory → device. If you can hang details on those five hooks, you can answer any "what happens when..." question.

Common confusion

"The OS was running the whole time." It was running for a few microseconds out of four seconds. The rest of the time it was sitting in memory doing nothing, exactly as Topic 1.1 said. It ran when a trap or an interrupt pulled it in, and not otherwise.

"The compile took 3.2 seconds, so the CPU was busy for 3.2 seconds." The compile job spent large parts of that in Waiting — on page faults, on disk reads, on a full log buffer. Other processes used the core during every one of those gaps. That overlap is the whole reason schedulers exist.

"Page faults mean something went wrong." The trace has one at 144 µs and many more after it, and the build succeeded. Faults are how demand paging loads a program.

Interview angle

"What happens when you press a key / click a button / run a program?" This is one of the most common opening questions in a systems interview, and it is deliberately open-ended.

They want to see how deep you can go and whether you stay in order.

Use the five anchors. Start at the interrupt, end at the device, and mention one number along the way — the 5 µs switch or the 100 µs fault. A candidate who says "the OS handles it" and a candidate who walks the chain are answering different questions.

"Which parts run in kernel mode?" A good follow-up to be ready for. The interrupt handler, the fork and exec calls, the page fault handler, the file open, the DMA setup. The compile itself runs entirely in user mode.