4.1.17 · D3Computer Architecture (Deep)

Worked examples — Working set model, thrashing

2,302 words10 min readBack to topic

Before anything, one reminder of the two quantities we juggle, in plain words:


The scenario matrix

Every question this topic can ask is one of these cells. The examples below are tagged with the cell they cover.

# Cell (case class) What makes it special Example
C1 High locality (many repeats) shrinks — few frames needed Ex 1
C2 Low locality (all-distinct stream) hits its ceiling Ex 2
C3 Phase change (locality set swaps) spikes then re-settles Ex 3
C4 (comfortable) slack frames, no thrash, room to add load Ex 4
C5 (exact break-even) the boundary — thrash or not? Ex 5
C6 (over-committed) thrashing; must suspend Ex 6
C7 Degenerate (, or string length) limiting behaviour of the window Ex 7
C8 Real-world word problem translate English → vs Ex 8
C9 Exam twist (PFF servo / low-CPU trap) apply the feedback reasoning, not the raw formula Ex 9

Read the "cliff" once more so C9 lands — the shape you must recognise:

Figure — Working set model, thrashing

C1 — High locality: repeats shrink the working set

Steps.

  1. Locate the window at . The last 4 references ending at position 4 are . Why this step? is defined as the distinct pages inside the last accesses — so first we physically slice out those accesses.
  2. Count distinct pages. . Why? The three s collapse to one page — the working set counts distinct pages, and repeats are exactly what locality produces.
  3. Slide to . Last 4 references: . Why? Same two hot pages dominate the whole loop — high temporal locality keeps demand flat and small.

Verify: A window of width 4 can at most hold 4 distinct pages, and at least 1. We got 2, comfortably inside . Sanity: the string only ever names pages 2 and 4, so can never exceed 2 anywhere. ✓ (Cell C1.)

Figure — Working set model, thrashing

C2 — Low locality: every page distinct

Steps.

  1. Window at : . Why this step? All four slots hold different pages — no collapsing happens.
  2. Window at : . Why? A pure streaming scan (array sweep, table scan) has no temporal locality — every reference is a brand-new page, so the window is always full of distinct pages.
  3. Read the ceiling. : the working set saturates its window. Why it matters? This is the worst case for demand paging — the working set model over-predicts, and larger would only pin more soon-dead pages (see the "bigger isn't always better" mistake in the parent).

Verify: always; here it equals the bound, the theoretical maximum for a window of 4. ✓ (Cell C2.)


C3 — Phase change: the working set spikes, then re-settles

Steps.

  1. (inside A): window . Why? Phase A is a tight loop over 2 pages — locality high, demand low.
  2. (the seam): window — take last 4 ending at ref 6: refs 3,4,5,6 . Why this step? The window still holds stale phase-A pages () and fresh phase-B pages () — during a transition both localities coexist, so demand temporarily rises.
  3. (inside B): refs 5–8 . Why? Once phase A pages age out of the window, only the new locality set remains.

Verify: Demand rose at the transition and held at — exactly the "spike at a phase change" the working set model is designed to catch. All counts lie in . ✓ (Cell C3.)

Figure — Working set model, thrashing

C4 · C5 · C6 — Comfortable, break-even, over-committed

These three share one arithmetic: total demand versus frames . We do all three signs at once so no case is left unshown.

  1. Sum the demand: . Why? Every runnable process needs its whole working set resident simultaneously, so demands add.
  2. Compare to supply: no thrashing, and frames are free. Why? Supply exceeds demand — everyone's live pages fit.
  3. Consequence: the scheduler may safely raise the Multiprogramming Degree — 3 spare frames could host a small third process.

Verify: , slack . ✓

  1. Sum: . Why? Same additive rule.
  2. Compare: . The thrashing condition is (strict), so is not thrashing — but there are zero spare frames. Why the strictness matters? At equality every working set just fits; nothing is evicted, so no fault-storm. But there is no margin: any tiny growth in one working set (a phase change) tips you straight into .
  3. Judgement: technically safe, operationally fragile — do not add load.

Verify: , , slack , and , so no thrash by the definition. ✓

  1. Sum: . Why? Additive live demand.
  2. Compare: thrashing — supply short by frames. Why this means thrash? Three frames' worth of live pages have nowhere to sit; they get evicted, immediately re-faulted, and the machine trades compute for disk seeks.
  3. Suspend the fix: drop (). New . Why ? It frees the most frames and lands comfortably below with slack — one suspension, problem solved.

Verify: before (thrash); after with slack . Suspending instead would give (also works) but leaves only slack ; suspending maximises breathing room. ✓ (Cells C4/C5/C6.)


C7 — Degenerate windows: the limits of

  1. (a) — smallest window. The window is just the single current reference . Why? One slot holds one page; a window of width 1 always gives . This is the degenerate under-estimate — it forgets everything, so it thrashes on any real program.
  2. (b) — window bigger than the whole history. You can only look back at references that exist: all 6, i.e. . Why? When (number of references so far), the window becomes the entire reference history — equals the total distinct pages ever touched. This is the degenerate over-estimate: it never forgets, so it pins stale pages forever.
  3. The takeaway on limits. As , climbs monotonically from up to (total distinct pages). The "right" sits between these extremes, matched to the locality-phase length.

Verify: (a) (forced by ). (b) distinct pages in whole string . Both inside . ✓ (Cell C7.)


C8 — Real-world word problem

  1. Frames available. Usable RAM bytes. Divide by page size : Why this step? The thrashing test is in frames, so convert every byte figure into frames first (units must match).
  2. Total demand. frames. Why? All 6 workers are runnable together, so their working sets add.
  3. Compare. no thrashing — the box is enormously over-provisioned for this tiny working set.
  4. How many workers fit? workers before would exceed .

Verify: , , ✓. Max workers: and . ✓ (Cell C8.)


C9 — Exam twist: the low-CPU trap and the PFF servo

  1. Test the working-set condition first. . Why? Before trusting the CPU meter, check whether demand physically fits — it does not (short by frames).
  2. Interpret the low CPU + high faults. Low utilization here means everyone is blocked on page faults, not that there is no work. Why this is the whole trick? The exam wants you to see that for the group is the cause of the idle CPU — the PFF law says "when everyone faults above and no free frames exist, suspend, don't add."
  3. Wrong move (the trap): adding process 4 raises to , shrinks each resident set, raises further, drives CPU below 15% — positive feedback into collapse.
  4. Right move: suspend . New , slack ; A and B stop faulting, CPU utilization recovers.

Verify: thrash before: ✓. After suspending : with slack ✓. Adding a 4th (say ) gives — strictly worse ✓. (Cell C9.)


Active recall

Recall Why does

never exceed ? Because the window holds exactly references, and distinct pages total references — repeats can only reduce the count. ::: So always, with the ceiling hit only under zero temporal locality.