Write-through vs write-back: Question bank — Hardware deep dive

This is a self-test page for Write-through vs Write-back Cache Policies. Every prompt hides a real reasoning trap — the kind that sounds right until you say the mechanism out loud. Cover the answer, commit to a yes/no and a reason, then reveal.

Before we start, four plain-word anchors used everywhere below. Each is built from scratch so this page stands on its own — no need to open any other note to follow it.

Definition The four words that carry this page

Dirty bit ::: a single 1-bit flag attached to each cache line (the fixed 64-byte chunk the cache stores as one unit) that means "this cached copy has been changed and memory does not know yet." 0 = memory matches, 1 = memory is stale.
Eviction ::: the moment the cache kicks a line out to make room for a new one. This is the only time write-back touches memory for a write.
Write buffer ::: a tiny FIFO queue (typically 4–8 slots) that catches writes headed for memory so the CPU can keep going instead of waiting for the ~100 ns memory write.
Write-allocate ::: the rule "on a write miss, first fetch the whole line into the cache, then write into it." The opposite is no-write-allocate: send the write straight to memory and skip the cache. Write-back caches almost always pair with write-allocate.

Below is the picture every question leans on — memorize where the ~1 ns and ~100 ns costs live, and when each policy pays them.

True or false — justify

True or false: In write-through, a read miss can never trigger a write to memory.

True — write-through keeps memory always current, so an evicted line is never dirty; there is nothing to flush, only the new line to fetch.

True or false: In write-back, a read miss can force a write to memory.

True — if the line being evicted to make room has its dirty bit set, that line must be flushed to memory before the new read-fetched line lands, even though the triggering access was a read.

True or false: The dirty bit exists in write-through caches too.

False — write-through lines are never newer than memory, so a dirty bit would always read 0 and carry no information; only write-back needs it.

True or false: Write-back always issues strictly fewer memory writes than write-through.

False — for reused lines it issues far fewer, but for a write-once-then-evict pattern write-back still pays exactly one memory write per line, matching write-through, so it can tie. "Always strictly fewer" is too strong; "never more" is the correct claim.

True or false: A write hit in write-back completes in about 1 ns regardless of workload.

True — a hit just updates the line and sets the dirty bit; no memory transaction is on the critical path. The 100 ns cost is deferred to eviction.

True or false: With a deep-enough write buffer, write-through write latency can approach cache latency.

True for bursts that fit the buffer — the CPU only sees

T_{cache} + T_{buffer-insert}

. It becomes false once the sustained write rate outruns the drain rate and the buffer fills, forcing stalls.

True or false: Write-back makes multi-core coherence simpler than write-through.

False — it makes it harder. Because memory can be stale, another core cannot trust memory and must locate the freshest copy in some other core's cache, requiring cache-to-cache transfers and snooping.

True or false: The dirty bit tracks exactly which bytes changed inside the line.

False — it is one bit per line, not per byte. Any write dirties the whole line, so eviction writes back all 64 bytes even if one byte changed.

Spot the error

"Write-back is faster because it never accesses memory on a store." — spot the error.

A write miss under write-allocate fetches the line from memory first, and if it evicted a dirty line it also flushes it — so a store can hit memory. Write-back avoids memory only on write hits.

"Since only one byte changed, write-back only sends that one byte to memory." — spot the error.

Memory transactions are line-granular bursts (~64 bytes on the DRAM bus); the writeback moves the entire line. Per-byte tracking would cost too much hardware for too little gain.

"Write-through's total write time is

T_{cache} + T_{memory}

, so about 101 ns." — is that always the observed CPU stall?

Not with a write buffer — the CPU sees only

T_{buffer-insert}

(~1–2 ns) and moves on; the 100 ns memory write overlaps with later work. The 101 ns is the transaction time, not necessarily the stall time.

"A read miss in write-back always costs

2 \times T_{memory}

." — spot the error.

The doubled cost only applies when the evicted line is dirty (one flush + one fetch). If the evicted line is clean it is simply discarded, and the miss costs the usual single

T_{memory}

"Write-back reduces bus traffic by 100× because cache is 100× faster than memory." — spot the confusion.

Two different ratios are being conflated. The 100× is a latency ratio (1 ns vs 100 ns). The traffic reduction comes from Miss Rate ×

P_{dirty}

(e.g. 0.05 × 0.5 ≈ 40×), not from raw speed.

"On eviction of a dirty line we fetch the new line first, then write the old one back." — spot the ordering error.

The stale-copy safety requires flushing the dirty old line to memory before the new fetch overwrites the cache slot; otherwise the only up-to-date copy of the old data would be destroyed.

Why questions

Why does write-through not need a dirty bit at all?

Because it guarantees memory is never behind the cache — every store propagates immediately — so a "memory is stale" flag would be permanently 0 and pointless.

Why is the writeback done at line granularity even for a single-byte store?

Because memory (DRAM) is written in fixed bursts, and the cache only records "this line differs" with one bit — it does not know which byte differs, so it must ship the whole line to be safe.

Why does temporal locality favor write-back so strongly?

Repeated stores to the same address hit the cache at ~1 ns each, and the expensive ~100 ns memory write is paid once on eviction — the memory cost is amortized across all those cheap writes.

Why can a write buffer help write-through but not remove the memory writes?

The buffer only hides latency by overlapping memory writes with CPU work; every store still eventually drains to memory, so total bus traffic is unchanged — the buffer trades stall time, not traffic.

Why does write-back complicate memory-consistency reasoning across cores?

Because the "true" latest value may live in a private cache and not in memory, other cores can observe stale memory, so ordering guarantees depend on the coherence protocol rather than on memory itself.

Why is write-through often preferred despite being "slower"?

Its simplicity, guaranteed up-to-date memory, and easier coherence make it attractive for small L1 caches or systems where correctness/simplicity outweigh peak write throughput.

Edge cases

Edge case: A line is written once, then immediately evicted (no reuse). Which policy wins?

Neither wins on traffic — both perform exactly one memory write. Write-back gains nothing to amortize here, which is why "write-back always wins" is false in this pattern.

Edge case: A pure streaming write workload (each address touched once, never reread).

Write-through with a deep write buffer is competitive and simpler, since write-back's deferral offers no reuse benefit and the buffer already hides latency for the sequential stream.

Edge case: The write buffer is full and a new store arrives.

The CPU stalls until a buffer slot drains to memory — stalls appear when the sustained write rate

R_{write}

exceeds the drain rate

N / T_{memory}

, so a "hidden" latency suddenly becomes visible.

Edge case: A cache line is dirty but the program never accesses it again. When does memory update?

Never, until the line is evicted or an explicit flush runs. This is why write-back can leave data stale indefinitely.

Edge case: Software needs the memory copy up-to-date now under write-back — how?

Use an explicit cache-flush instruction (e.g. CLFLUSH/CLWB on x86) to force the dirty line back to memory, and a memory fence to order it, since normal execution only writes back on eviction.

Edge case: Two writes to the same line under write-back before any eviction. How many memory writes?

Exactly one — both stores set/keep the dirty bit, and the single eviction flushes the final combined line once.

Edge case: Zero writes but many read hits. Do the policies differ?

No — with no stores there is nothing to propagate or defer, no line ever becomes dirty, so write-through and write-back behave identically. The whole distinction is a write problem.

Recall One-line summary to lock in

Write-through = memory always fresh, pay per store, no dirty bit, easy coherence. Write-back = cache fresh only, pay per eviction, dirty bit required, best with reuse, harder coherence, needs explicit flush to force memory current early.

Related notes: Hinglish version · 5.4.01-CacheFundamentals · 5.4.05-Cache-ReplacementPolicies · 5.4.07-Cache-Coherence · 5.4.08-Write-Allocate-vs-No-Write-Allocate · 6.2.03-Memory-ConsistencyModels · 5.3.02-DRAM-Architecture