Cross a privilege boundary without changing tasks

A processor's privilege mechanisms restrict operations such as configuring address translation or directly controlling devices. Ordinary application instructions execute with user privileges; the operating system establishes controlled entry points for requesting protected services. A transition through an allowed entry point does not grant an application unrestricted access to kernel code. The kernel still interprets arguments, checks access, and decides whether to perform an operation. Hardware privilege is also distinct from an operating-system account: an application running under a privileged account still normally executes its application instructions in user mode.

Imagine thread A requesting an operation that completes immediately. The processor can enter the kernel, execute on behalf of A, and return to A's next user instruction without selecting thread B. That is a privilege transition with no scheduler switch to a different task. Conversely, a scheduling decision can switch between two tasks while execution is already inside the kernel. Keep separate counts for boundary crossings and task switches. Calling both events a context switch hides which mechanism a trace actually measured and encourages unjustified performance comparisons.

A blocking request adds another distinction. When an operation cannot proceed, the calling thread may sleep and another runnable thread may be selected. After the dependency completes, the original thread can become runnable without immediately receiving a processor. The eventual return to user space may therefore include kernel CPU service, off-CPU blocked time, and runnable delay. A long elapsed system-call duration is not evidence that the CPU executed kernel instructions throughout that interval. This matters when a slow storage dependency is mistakenly treated as a processor bottleneck.

Build a timeline with mutually exclusive categories for the thread being investigated. While it runs, label user execution or kernel execution; while it does not run, distinguish waiting for a condition from waiting for scheduling. Define how interruptions are charged before adding the intervals. A hardware interrupt can consume a CPU while the application's thread identity remains associated with that CPU, but its handler is not the application making progress. Accounting tools may present these categories differently, so compare definitions before comparing their percentages or drawing conclusions about work that should be optimized.

A library call is a source-level interface, whereas a system call is an interface to the kernel. A buffered library write may only copy data into a user-space buffer until a later flush. Some time-query APIs can use a kernel-provided vDSO mapping to read suitable information without a fresh kernel entry. Other wrappers may perform several operations or choose a fallback path. The mapping depends on the function, architecture, library, and running kernel. Trace the actual execution when the distinction matters rather than counting function names in source code as system calls.

Use the queue lab to separate waiting work from the mechanism that admits it. Compare two separate fixed-rate runs. For each run, press Reset, re-set both rates, predict the backlog direction, then press Play or Step. First use arrival rate 4 and service rate 3 to inspect growth; reset again and set arrival rate 2 and service rate 3 to inspect a fresh draining run. The second run starts from four jobs, not the first run's final backlog. This fluid model starts with four jobs and does not represent privilege modes, interrupts, or a scheduler. Its useful connection is narrower: an observed delay can increase because work waits longer, even when a single operation's CPU service is unchanged. Test that hypothesis with CPU-time and off-CPU measurements instead of inferring it from elapsed latency alone.