Write policies — write-through, write-back, write-allocate: Question bank

Definition Notation and shorthand used on this whole page

Before any trap, here is every symbol and abbreviation, in plain words, so nothing is used before it is defined:

Hit = the block you want is already in the cache. Miss = it isn't.
Dirty bit = one extra bit per cache line meaning "this copy was changed and memory does not know yet."
Eviction = kicking a block out of a cache line to make room for a new one (a replacement decision).
W x = the CPU writes a value to memory address x. R x = the CPU reads address x. A sequence like W x; W x; R x is just those operations in order on a starting cache state.
SRAM = static RAM, the fast, expensive memory the cache is built from. DRAM = dynamic RAM, the slow, cheap memory main memory is built from — roughly 100× slower to reach than SRAM. ("RAM" just means the read/write working memory.)
WT = write-through (on a write hit, update cache and memory now). WB = write-back (on a write hit, update cache only, set the dirty bit, defer memory).
WA = write-allocate (on a write miss, fetch the block into cache first, then write). NWA = no-write-allocate (on a write miss, write straight to memory, do not cache).
$t_{c}$ = time to access the cache (fast, SRAM). $t_{m}$ = time to access one block of main memory (slow, DRAM). $m$ = the write-miss rate, the fraction of writes that miss. $d$ = the dirty-victim fraction: of the blocks we evict, the fraction that are dirty and therefore must be written back before their line is reused.

Figure — Write policies — write-through, write-back, write-allocate

Formula The cost formulas — built up event by event (every symbol above)

A write's cost is just the sum of the time of each thing it forces to happen. Let's build each formula from its events rather than quoting it.

Write-through with no-write-allocate (WT + NWA) — the natural WT pairing:

On a hit (probability $1 - m$ ): write the cache line and memory → $t_{c} + t_{m}$ .
On a miss (probability $m$ ): NWA does not touch the cache, it writes memory directly → $t_{m}$ only (no $t_{c}$ ). $T_{WT+NWA} = (1 - m) (t_{c} + t_{m}) + m t_{m} = t_{c} (1 - m) + t_{m}$ Why: memory is written on every write (both branches contain $t_{m}$ ), so the slow $t_{m}$ is unavoidable each time; the cache access $t_{c}$ only appears on the hit branch, because on a miss NWA skips the cache.

Write-back with write-allocate (WB + WA) — the natural WB pairing:

On a hit (probability $1 - m$ ): update the cache line only → $t_{c}$ .
On a miss (probability $m$ ): fetch the block ( $t_{m}$ ); and if the victim we evict is dirty (fraction $d$ ), first write it back ( $d t_{m}$ ); then write the cache → the $t_{c}$ is dwarfed and folded into $t_{c}$ . $T_{WB+WA} = t_{c} + m (t_{m} + d t_{m}) = t_{c} + m t_{m} (1 + d)$ Why: every slow $t_{m}$ event lives inside the miss branch, so the whole $t_{m} (1 + d)$ chunk is weighted by $m$ . With good locality $m$ is tiny, so memory is touched only rarely.

Read the two side by side: WT pays $t_{m}$ every write; WB pays $t_{m}$ only a fraction $m$ of the time. Figure s03 graphs $T_{WB+WA}$ against $m$ so you can see the $t_{m}$ term switch on only as misses grow.

True or false — justify

The two axes never mix on the same event

True — WT-vs-WB is decided on a write hit, WA-vs-NWA on a write miss. A single access is either a hit or a miss (see figure s02), so only one axis ever fires per write.

Write-back (WB) updates memory on every write

False — it updates only the cache line and sets dirty=1; memory is touched only when that dirty line is later evicted. That deferral is the entire point.

Write-through (WT) never needs a dirty bit

True — because memory is updated on every write, the cache copy and memory are always equal, so there is never a "stale memory" state to record.

A clean block (dirty=0) can be evicted with zero memory writes

True — clean means the cache copy already equals memory, so you just overwrite the line; nothing needs saving.

Reads can also cause a block to be loaded into cache

True — a read miss allocates the block regardless of write policy. WA/NWA only govern write misses, not reads.

Write-allocate (WA) makes the first write to a fresh block a hit

False — the first write is still a miss; WA responds to that miss by fetching the block, and only then completes the write as if it were a hit. The miss already happened.

No-write-allocate (NWA) means the written value is lost

False — the value is written straight to memory, so it is safely stored; it simply is not cached, so a later read of it will miss.

Write-through with a write buffer can feel as fast as write-back on writes

True on the CPU side — the buffer absorbs the store and the CPU continues; but the underlying memory traffic is still one write per store, so bandwidth is unchanged. See Write Buffers and Store Buffers.

Two independent axes give four legal combinations

True — all four are definable (the four boxes of figure s01), but only WB+WA and WT+NWA are natural; the other two combine costs without matching benefits.

Write-back always writes less to memory than write-through

False in general — for a workload that writes each block exactly once and never revisits it, WB still writes it back on eviction, so traffic can be equal; WB only wins when locality lets many writes collapse into one write-back.

Spot the error

For each, the picture to hold in mind is figure s01 (the 2×2 axes) or s02 (the hit/miss split) — that is what makes each correction concrete rather than a slogan.

"On a write miss, write-back fetches the block, so write-back is the same as write-allocate."

Confuses the two axes of figure s01. WB is the hit policy (vertical axis); the fetch-on-miss behaviour is write-allocate, the miss policy (horizontal axis). They pair up conventionally but are separate decisions.

"Write-through is obsolete because it is slower."

Wrong metric. WT is simpler, needs no dirty bits, and keeps memory always coherent — valuable for coherence and I/O visibility. "Slower on write traffic" ≠ "useless."

"With no-write-allocate, the cache line for the address becomes dirty."

Impossible — NWA never brings the block into cache, so there is no line and no dirty bit to set; the value went to memory directly (the NWA branch of figure s02 never touches the cache).

"After W x on a cold WB+WA cache, the block is clean because we just fetched it."

The fetch loads clean data, but the write that follows modifies it, so the line ends dirty=1. The write is the whole reason we fetched.

"Evicting a dirty block means we lose its data."

The opposite — because it is dirty, the eviction first writes it back to memory, then reuses the line. Dirty data is preserved precisely by write-back on eviction.

"Write-through means the CPU always stalls waiting for DRAM."

Only if there is no buffer. A write buffer queues the store so the CPU proceeds; it stalls only if the buffer is full (see the dedicated edge case below).

"Because reads outnumber writes, the write policy barely affects performance."

Misleading — write-heavy inner loops (counters, accumulators, stacks) are common, and there memory traffic is dominated by writes; policy choice can swing memory traffic by an order of magnitude (that is the

t_{m}

-vs-

m t_{m}

gap in figure s03).

Why questions

Why does write-back (WB) need a dirty bit but write-through (WT) does not

The dirty bit records whether memory is behind the cache. WB deliberately lets them differ, so it must track which lines are stale; WT never lets them differ, so there is nothing to track.

Why is no-write-allocate (NWA) a good fit for memset-style streaming writes

You overwrite whole blocks you never read back. WA would waste bandwidth fetching a block just to clobber it entirely; NWA skips that useless fetch and writes straight through.

Why do the slow memory terms in the write-back cost get multiplied by the miss rate

Start from

T_{WB+WA} = t_{c} + m t_{m} (1 + d)

. A hit costs only

t_{c}

; memory is touched only on a miss (fetch,

t_{m}

) and on a dirty eviction (extra

d t_{m}

). Both memory events live inside the "miss" case, so the whole

t_{m} (1 + d)

chunk gets weighted by

m

— the slope you see in figure s03.

Why is write-through (WT) paired with no-write-allocate rather than with write-allocate

A WT miss already sends the value to memory; loading the block too (WA) would add a fetch of

t_{m}

with no benefit, since the next write goes to memory anyway. So WT+NWA drops that fetch — the WT+NWA box of figure s01.

Why can locality make write-back dramatically cheaper than write-through

Programs rewrite the same hot locations repeatedly. WT pays a memory write each time; WB collapses all of them into one write-back at eviction, so N writes cost roughly one memory access instead of N — a small

m

in figure s03.

Why is write-through sometimes preferred in multiprocessor systems

Because memory always holds the current value, other cores and DMA agents see up-to-date data without waiting for an eviction, simplifying coherence and I/O correctness.

Why is "allocate vs no-allocate" meaningless on a write hit

Allocation means making room in the cache for a block. On a hit the block is already there, so there is nothing to allocate — the decision only exists when the block is absent (the miss branch of figure s02).

Edge cases

A write hits, then the block is evicted while still clean — how

In pure WB a write hit always sets dirty=1, so a genuinely written line evicts dirty. A line can be clean at eviction only if it was read-only or was fetched but never written. ::: Under WT the line is always clean on eviction, since memory tracked every write.

A block is written, evicted (dirty → written back), then loaded again and read — what does the read return

The correct, up-to-date value: the dirty eviction pushed the latest data to memory, so the later fetch reloads exactly that. No staleness because the write-back happened before the reload.

Cold cache, NWA, sequence W x; W x; R x — what happens on the read

Both writes go to memory and never cache the block, so R x is a miss that must load the block (reads allocate). The write policy never cached it, so the read pays the fetch.

Write buffer is FULL under write-through — what happens

The CPU must stall on the next store until the buffer drains one slot to memory. WT normally hides

t_{m}

behind the buffer, but a full buffer exposes the raw

t_{m}

again — the boundary where WT's "feels fast" claim breaks. See Write Buffers and Store Buffers.

A dirty line's power is lost before eviction (crash)

The un-written data in the dirty line is lost — WB's deferral is exactly a durability risk window. WT would have no such window since memory was always current (relevant to persistence and I/O consistency).

Same address written by CPU and read by DMA under write-back

The DMA can read stale memory because the fresh value sits dirty in cache and hasn't been evicted. This is why DMA requires cache flush/invalidate or hardware coherence.

Write-allocate on a fully-associative empty cache, first write

It is a miss, so the block is fetched into any free line and then written, ending dirty=1. Even with room to spare, the fetch still happens — WA always brings the block in on a write miss.

A block mapped to a line holding a clean victim — write miss under WB+WA

Fetch the new block into that line and write (dirty=1); the clean victim is simply overwritten with no write-back, because clean means memory already matches it.

Recall One-line self-test before you close

Hit axis vs Miss axis? ::: Hit → write-through (WT) vs write-back (WB); Miss → write-allocate (WA) vs no-write-allocate (NWA). They are independent and never fire on the same access.

Prerequisites and neighbours: Cache Memory Fundamentals · Cache Replacement Policies · Memory Hierarchy and AMAT · Write Buffers and Store Buffers · Cache Coherence — MESI · DMA and I/O Consistency · Parent: Write Policies.