Exercises — System calls — user mode vs kernel mode, trap mechanism

Recall the parent's three doors: trap = synchronous and intentional; exception = synchronous but accidental; interrupt = asynchronous, from outside hardware.

• (a) Trap — you deliberately executed syscall.
• (b) Exception (fault) — an instruction went wrong, not requested.
• (c) Interrupt — the keyboard is external hardware, unrelated to your current instruction.
• (d) Exception (fault) — synchronous (caused by this load instruction) but unintended. (See Interrupts and Exceptions and Virtual Memory and Page Tables.)
• (e) Interrupt — the timer chip is asynchronous hardware.

• (a) False. Same CPU, same registers — only the mode bit differs. "Supervisor" is a state, not extra silicon.
• (b) True. The instruction exists in the instruction set; in user mode the hardware turns its execution into a fault instead of running it.
• (c) False. A syscall always does a mode switch (same process, into the kernel). It only sometimes triggers a context switch — e.g. if it blocks.

mov rax, 39      ; syscall number -> the index into the kernel's trusted table
syscall          ; the trap: flips mode bit, jumps to fixed kernel entry
; rax now holds the returned PID

Why rax for the number? The ABI fixes rax as the number register so both sides agree without negotiation. Why syscall and not call? A call stays in user mode and jumps to a user address; only syscall is allowed to flip the mode bit and land at the pre-registered handler. Why does the answer arrive in rax? The same ABI fixes rax as the return register.

Buffered: all 1000 formats are user-space work — they cross nothing. Only the single final write crosses. Boundary cost $=1\times 300=300$ cycles. Unbuffered: every printf ends in its own write, so $1000$ crossings: $1000\times 300=300,000$ cycles. Ratio: $300,000/300=1000\times$ more boundary cost. The formatting ($1000\times 50=50,000$ cycles) is identical in both — buffering changes only the count of traps, which is exactly the parent's 80/20 insight. (This is the seed of io_uring and Batched I/O.)

B → E → C → F → A → D. Reason each hand-off: you must set up the request (B) before triggering it (E); the trap instruction only starts the atomic hardware transfer (C); the kernel can only run after it has control, and must validate before trusting (F); it computes and stashes the result (A); finally return-from-trap flips the mode back (D). See the figure below.

$T_{\text{old}}(N)=N(T_{\text{cross}}+T_{\text{work}})=N(300+200)=500N$ $T_{\text{new}}(N)=T_{\text{cross}}+N{T}_{\text{work}}=300+200N$ Speedup: $S(N)=\frac{500N}{300+200N}.$ As $N\to \infty$ the constant $300$ becomes negligible: $S\to 500/200=2.5$. So batching this workload can be at most 2.5× — the crossing was only 300 of the 500 cycles per call. Analysis point: batching helps a lot when $T_{\text{cross}}$ dominates $T_{\text{work}}$; here the work is heavy, so the ceiling is modest.

$T_{\text{old}}(4)=500\times 4=2000$ cycles. $T_{\text{new}}(4)=300+200\times 4=1100$ cycles. Speedup $=2000/1100\approx 1.818$. Notice it is well below the $N\to \infty$ ceiling of $2.5$, because at small $N$ the single saved crossing is a smaller fraction of the total.

The other terms ($T_{\text{mode-switch}}$, $T_{\text{save/restore}}$, $T_{\text{validate}}$) are paid inside the syscall. But while the kernel ran, it touched its own code and data, evicting your program's data from the CPU caches and its address translations from the TLB. After sysret, your code resumes but its next memory accesses now miss and must refetch from slower memory. That penalty is charged after the syscall returns, so a "cheap" syscall can silently slow down the code that follows it. This delayed, invisible cost is the strongest argument for reducing syscall count.

• (a) Mode switch only — same process, user → kernel via the trap.
• (b) Context switch — the kernel voluntarily hands the CPU to a different process (see Process Scheduling). Your process stays in kernel mode, sleeping; another process starts running. This is why blocking I/O doesn't freeze the machine.
• (c) Neither for your process directly — the interrupt is a mode switch for whatever process was running, and its handler just flips a flag ("runnable"); your process isn't executing yet.
• (d) Both — a context switch back into your process, and it finishes in kernel mode then does a mode switch out to user as read returns. Synthesis point: one logical read call spans multiple mode switches and multiple context switches, spread across time and across other processes. A syscall is a story, not a single instant.

Why fixed: the whole protection wall relies on user code entering the kernel only at a point where validation happens first. If user space supplied the entry address, a malicious program could point it past the validation code — for example straight into the routine that writes a disk sector, skipping the "is this pointer legal?" checks. What would break: the invariant "no privileged action runs without a check" collapses; the mode bit would still flip to kernel, but now with attacker-chosen code executing at full privilege. So the kernel registers one entry address at boot (the trap handler), and the syscall instruction hard-wires the jump there — user code cannot influence where it lands, only what number it requests. This is the same principle as ring 0 being unreachable except through guarded gates.

(a) Fixed overhead $=120+90+40+250=500$ cycles, so $T_{\text{syscall}}=500+T_{\text{work}}.$ (b) Overhead equals work when $T_{\text{work}}=500$ cycles. (c) With $T_{\text{work}}=100$:

• Unbatched: $8\times (500+100)=8\times 600=4800$ cycles.
• Batched: $500+8\times 100=500+800=1300$ cycles. Speedup $=4800/1300\approx 3.69\times$. Batching pays one $500$ overhead instead of eight.

• (a) General-protection fault (an exception, not a trap). The mode bit says "user," the silicon refuses HLT, and control goes to the kernel's fault handler — which typically kills the process with a signal. No privileged action occurs.
• (b) The kernel's validation step (step F) sees the index is outside the table bounds and returns an error (-ENOSYS in rax), without dispatching. This is exactly why the number must be validated before use.
• (c) The number is fine, so the kernel dispatches, but when it tries to touch buf it hits an unmapped page → the kernel's access faults, is caught, and the syscall returns -EFAULT. The wall protected the kernel from a bad user pointer.
• (d) There is no mode switch to make (already kernel), but the crossing overhead of a full user→kernel trap is avoided; in practice the kernel calls its service function directly rather than issuing syscall. The key invariant — validation before privileged work — still holds.
• (e) You still pay the entire fixed overhead ($T_{\text{mode-switch}}+T_{\text{save/restore}}+T_{\text{validate}}+T_{\text{cache/TLB}}$) even though $T_{\text{work}}=0$. This is the sharpest proof that the crossing itself costs, independent of the work — the whole motivation for avoiding needless syscalls.

Empty syscall cost $=500+0=500$ cycles. Useful syscall cost $=500+5000=5500$ cycles. Number of empty syscalls fitting in one useful one: $5500/500=11$. So eleven pointless boundary crossings cost as much as one real, heavy syscall. Interpretation: overhead is not "free rounding error" — a program that sprays tiny syscalls can burn its budget on nothing but doorways.

Trap vs fault vs interrupt? ::: Trap = synchronous + intentional; fault = synchronous + accidental; interrupt = asynchronous. Why a syscall number instead of an address? ::: The kernel trusts only its own table index, never a user-supplied jump target. Mode switch vs context switch? ::: Mode switch stays in one process (privilege changes); context switch swaps processes. Where does batching's speedup ceiling come from? ::: The ratio of crossing overhead to real work — bounded, not infinite.