Summary Dialogue on CPU Virtualization

Essential Hardware Mechanisms for Processor Sharing

Sharing one CPU among many programs requires traps, privilege transitions and a periodic timer. Hardware automatically saves key state and enters the kernel on exceptions or interrupts; the OS then completes a full context save and restore so a paused program resumes at the exact instruction. Without these pieces any user program could monopolize the processor forever.

Limited Direct Execution and the OS Desire for Control

For speed the OS lets user code execute natively on the hardware, yet user/kernel modes plus periodic checks let it seize control at any moment. The design seeks efficiency while remaining highly wary of buggy or hostile programs, keeping the OS firmly in the role of resource manager.

Inherent Conflicts in Scheduling Policies

Advancing short tasks improves turnaround time while round-robin improves interactive response. Multi-level feedback queues try to approach both goals at once, yet the metrics oppose each other, so no algorithm is optimal for every workload. A pragmatic engineer focuses on steering clear of catastrophic outcomes rather than hunting a theoretically perfect policy.

Practical Take-aways from Classroom to Cloud

Knowing these internals helps schedule jobs reasonably or diagnose latency in shared cloud environments. It also reminds us that schedulers can be used strategically, so real systems must account for adversarial behavior instead of assuming every user cooperates in good faith.

Pitfalls

• Assuming cooperative processes will always yield the CPU and therefore omitting a mandatory timer.
• Choosing time slices that are too short without accounting for real context-switch cost.
• Believing one scheduling algorithm can be optimal for every possible workload.

Minimum C11 · complete program · Download .c

#include <stdio.h>

int main(void) {
    int t;
    const char *jobs[2] = {"ProcA", "ProcB"};
    int cur = 0;
    for (t = 0; t < 8; t++) {
        printf("[%d] executing %s\n", t, jobs[cur]);
        if ((t + 1) % 3 == 0) {
            printf("    * timer fires, context switch from %s\n", jobs[cur]);
            cur = 1 - cur;
            printf("    * resume %s\n", jobs[cur]);
        }
    }
    return 0;
}

Compile locally

gcc -std=c11 -Wall -Wextra -Wpedantic -Werror ostep-11-cpu-summary.c -o example && ./example

Expected result

[0] executing ProcA
[1] executing ProcA
[2] executing ProcA
    * timer fires, context switch from ProcA
    * resume ProcB
[3] executing ProcB
[4] executing ProcB
[5] executing ProcB
    * timer fires, context switch from ProcB
    * resume ProcA
[6] executing ProcA
[7] executing ProcA

CHECK YOUR UNDERSTANDING

Close the answer. Explain it.

Even if every process cooperates by making system calls, why must the OS still employ a timer interrupt?

Check the sources

• OSTEP chapter PDF

Drafts and official chapters change. The version mark is only the example’s minimum.