Exercise 3: Quantum Size Trades Switch Overhead Against Responsiveness — Possible Solution
====================================================================

THE TEST
------------------------------
    TOTAL_INSTR = 200
    # 3 processes, none ever calling run_cooperative()
    # run once with QUANTUM=1, once with QUANTUM=20

RESULT
------------------------------
    QUANTUM=1:  200 real context switches over 200 instructions
    QUANTUM=20:  10 real context switches over 200 instructions

Both runs perform the exact same amount of real work (200 total
instructions across the same 3 processes) -- the only thing that
changed is QUANTUM. QUANTUM=1 forces a switch after literally every
single instruction; QUANTUM=20 lets each process run 20 instructions
before being interrupted.

WHY THE NUMBERS COME OUT EXACTLY THIS WAY
------------------------------
Each quantum, once the fixed reset is in place, is a real, full
QUANTUM instructions long (confirmed directly in the chapter's own
Finding 3 fix). Over a fixed total of 200 instructions, the number of
quanta that fit is simply 200 / QUANTUM:

    200 / 1  = 200 switches
    200 / 20 = 10 switches

This isn't a coincidence of this particular run -- it's the direct,
mechanical consequence of run_instruction() dispatching the timer
interrupt exactly once every QUANTUM instructions, every time.

THE REAL TRADEOFF THIS REVEALS
------------------------------
Every one of those switches is a real call to context_switch_fixed()
-- Chapter 5's own genuine save-then-load of a full register
dictionary, plus two real ProcessState transitions. QUANTUM=1 pays
that full cost 20 times more often than QUANTUM=20, for the identical
amount of actual instruction execution. That's real, measurable
overhead spent entirely on bookkeeping, not on any process's own
forward progress.

The other side of the tradeoff is responsiveness: with QUANTUM=20, a
process that starts misbehaving (an infinite loop, like Finding 1's
own selfish process) can hold the CPU for up to 20 instructions
before the timer can even attempt to preempt it. With QUANTUM=1, the
same misbehaving process is interrupted almost immediately -- at the
direct cost of the switch overhead measured above. A real kernel's
quantum size is exactly this kind of engineering tradeoff: how much
raw throughput is worth trading for how quickly the system can react
to any single process.

WHY THIS WORKS AS AN ANSWER
------------------------------
Holding every other variable fixed (same 3 processes, same 200
instructions, same code) and changing only QUANTUM isolates its
effect precisely -- the measured switch counts (200 vs. 10) are a
direct, verified reading of the actual tradeoff, not an assumption
about what "should" happen with a smaller or larger quantum.