5.4.6 · D3 · HinglishMemory Hierarchy & Caches

Worked examplesWrite-through vs write-back

3,275 words15 min read↑ Read in English

5.4.6 · D3 · Hardware › Memory Hierarchy & Caches › Write-through vs write-back

Yeh page "sab kuch ek jagah" wali workbench hai parent topic ke liye. Hum har tarah ki situation list karenge jo ek write policy face kar sakti hai, phir har ek ke liye ek concrete problem solve karenge. Yahan kuch bhi assume nahi kiya gaya ki tumne formulas pehle se yaad kar rakhe hain — har symbol tab earn hota hai jab woh pehli baar appear karta hai.

Shuru karne se pehle, teen plain-language reminders taaki koi symbol akela na rahe:


Scenario matrix

Har write problem kuch independent switches ka combination hai. Yeh raha poora grid — baad ke har example ko uski cell ke saath tag kiya gaya hai (jaise C3).

Cell Policy Access outcome Line state Kya special hai
C1 Write-through write hit baseline: har baar memory pay karo
C2 Write-through bahut saare writes, buffered write buffer latency chhupa leta hai jab tak fill na ho
C3 Write-back write hit, clean→dirty clean then dirty "1 ns" wala happy path
C4 Write-back bahut saare writes, same line stays dirty temporal locality → amortisation
C5 Write-back write miss, evict clean line victim clean [[5.4.08-Write-Allocate-vs-No-Write-Allocate
C6 Write-back write miss, evict dirty line victim dirty double memory hit (writeback + fetch)
C7 Degenerate write-once stream, no reuse dirty once limiting case: write-back apna edge khota hai
C8 Both full head-to-head count mixed real-world word problem
C9 Multi-core twist ek core dirty, doosra reads dirty elsewhere [[5.4.07-Cache-Coherence

Yeh nau cells cover karti hain: dono policies, hit aur miss, clean aur dirty victims, buffered case, zero-reuse limit, ek real workload, aur multi-core edge.

Ek aur policy word cells C5–C7 mein aata hai, toh pehle use earn kar lete hain:

Ab hum har cell solve karte hain.


C1 — Write-through, single write hit

  1. Cache line update karo: Cache[0x100] ← 99. Yeh step kyun? Write-hit matlab line present hai, toh cache copy pehle change honi chahiye. Cost .
  2. Same store ko memory ko immediately forward karo: Mem[0x100] ← 99. Yeh step kyun? Yahi write-through ki definition hai — memory ko peeche rehna allowed nahi. Cost .
  3. Dono add karo kyunki CPU dono ke finish hone ka wait karta hai:

Verify: memory term () cache term () ko dwarf karta hai, toh — parent note ke "memory dominates" claim se match karta hai. Units: ns + ns = ns. ✓


C2 — Write-through with a write buffer

Write buffer ek tiny queue hai (depth ) jo stores pakadti hai taaki CPU ko memory ka wait na karna pade.

  1. Buffer sirf utni tezi se empty ho sakta hai jitni tezi se memory drains accept kare: ek slot har mein nikalta hai. Toh sustained drain rate hai Yeh step kyun? Long-term throughput slowest stage se set hoti hai — yahan single memory port — buffer mein kitne slots hain usse nahi.
  2. Phir depth kya deta hai? Yeh ek temporary burst absorb karta hai: agar writes briefly drain ko outrun karein, toh queue ho sakte hain buffer full hone se pehle. Lekin jab woh spare slots use ho jaate hain, CPU drain se tez nahi ja sakta. Toh sustained stall condition hai Yeh step kyun? badalta hai ki tum drain rate se kitni der exceed kar sakte ho, drain rate khud nahi — deeper buffer sirf pehla stall postpone karta hai.
  3. Writes per second mein convert karo taaki number human-readable ho, aur confirm karo ki threshold ek real CPU issue rate se tied hai: Yeh step kyun? CPU store rates writes/second mein quote ki jaati hain; convert karne se hum stall threshold ko chip ki actual sustained store rate se directly compare kar sakte hain. Jo bhi workload is buffer mein M writes/s se zyada issue karta hai woh eventually stall karega.

Verify: ek tez CPU (bada ) threshold jaldi cross karta hai → pehle stall karta hai. Limit sanity check: jaise (instant memory) threshold , matlab koi stall possible nahi — sahi hai. Dhyan do ki sustained threshold mein kabhi appear nahi karta, bilkul expected ke anusaar. ✓


C3 — Write-back, single write hit (clean → dirty)

  1. Cache line update karo: Cache[0x100] ← 99. Cost .
  2. Sticky note set karo: Dirty ← 1. Yeh step kyun? Memory abhi bhi 42 hold karti hai. Dirty bit ek maatra record hai ki future writeback owed hai. Set karna koi extra time nahi leta (yeh write ke saath saath flip hoti hai).
  3. Khatam. Koi memory access nahi. .

gaaye nahi — woh eviction time tak defer ho gaye. C1 se compare karo:

Verify: step 2 ke baad memory 0x100 abhi bhi 42 equal karti hai — exactly woh "inconsistent but faster" state jo policy promise karti hai. ✓


C4 — Write-back, same line par bahut saare writes (amortisation)

Yeh woh cell hai jahan write-back apni value prove karta hai — temporal locality.

  1. 1000 writes mein se har ek hit hai → . Yeh step kyun? Har write ek already-present, already-dirty line hit karta hai, toh koi write kabhi memory touch nahi karta.
  2. Eviction par, ek memory write final value flush karta hai: . Yeh step kyun? Memory ko sirf aakhri value chahiye, saari 1000 nahi — yahi amortisation hai.
  3. Total: .
  4. Write-through har write par memory pay karta: .
  5. Speedup:

Verify: parent note ke "" numerical example se match karta hai. Memory traffic: 1 write (WB) vs 1000 writes (WT) → kam bus traffic. ✓


C5 — Write-back, write miss, victim line clean hai

Ab address cache mein nahi hai. Write-allocate ke under, hum pehle line pull karni padegi.

  1. Slot ka current occupant clean hai → bas discard karo, koi writeback owed nahi. Cost . Yeh step kyun? Clean matlab cache aur memory already agree karte hain; overwrite karne se kuch nahi jata.
  2. Fetch karo 0x200 line memory se cache mein: . Yeh step kyun? Write-allocate kehta hai "line andar lao, phir write karo" (taaki 0x200 ke future writes saste hits ban jayein).
  3. Ab freshly-loaded line mein write karo aur dirty set karo: , Dirty ← 1. Yeh step kyun? Store instruction ko abhi bhi actually value 7 deposit karni hai; line fetch karna sirf jagah banata hai, write perform nahi karta. Aur hum line ko dirty mark karte hain kyunki yeh nayi value 7 ab us se alag hai jo memory hold karti hai — warna baad ki eviction use silently khoh degi.
  4. Total: .

Verify: exactly ek memory access (fetch), kyunki victim clean tha. Yeh do miss cases mein se sasta wala hai — agle C6 se contrast karo. ✓


C6 — Write-back, write miss, victim line dirty hai

Sabse bura common case: jis line ko hum evict karna chahte hain woh abhi bhi memory writeback owed karti hai.

  1. Pehle dirty victim ko memory mein write back karo: . Yeh step kyun? Dirty bit kehta hai ki us purane address ke liye memory stale hai; hum newer data nahi khoh sakte.
  2. Memory se 0x200 line fetch karo: . Yeh step kyun? Write-allocate require karta hai ki target line resident ho pehle hum us mein write karein; slot ab empty hai (hum abhi victim flush kar chuke hain), toh 0x200 pull karein.
  3. Us mein write karo, dirty set karo: . Yeh step kyun? Same reason C5 step 3 ki tarah — actual value 7 abhi bhi line mein land karni hai, aur dirty mark karna record karta hai ki yeh nayi value ab memory se alag hai taaki future eviction use flush kare.
  4. Total:

Verify: do memory accesses = plus tiny cache write — parent ke "" eviction cost se match karta hai. Yeh C5 se bura hai, exactly ek extra . ✓


C7 — Degenerate case: write-once stream, no reuse

Limiting scenario jahan write-back ki amortisation collapse ho jaati hai.

  1. Write-back per write = full C6 cost (writeback victim + fetch + cache write) = har baar. Yeh step kyun? No reuse matlab C4 ki amortisation kabhi nahi hoti — har write full miss pay karta hai.
  2. Total WB .
  3. Write-through yahan write-no-allocate use karta hai (matrix mein defined): miss par write seedha memory ko jaati hai, cache load nahi hota aur koi cache line nahi likhi jaati. Toh har write sirf ek memory access cost karta hai: Yeh step kyun? No reuse ke saath cache line allocate karne mein kuch gain nahi hai, toh write-no-allocate fetch aur deposit dono skip karta hai — value simply DRAM ko push hoti hai. (Agar hum write-through with allocate use karte, toh hum ek fetch aur cache write add karte, dete — lekin no-allocate streaming write pattern ke liye sensible pairing hai.)
  4. Total WT .
  5. Ratio:

Verify: write-back ab slower hai — C4 ka exact opposite. Yeh parent ke Mistake 1 ko confirm karta hai: "write-through hamesha slower nahi hoti." Crossover zero temporal locality ki wajah se hota hai. ✓


C8 — Real-world word problem: full head-to-head

  1. Write-through memory writes = har store: Yeh step kyun? Definition se WT har store par memory touch karta hai.
  2. Write-back memory writes = sirf dirty evictions: Yeh step kyun? Memory write tab hoti hai jab line both evict ho (miss rate) aur dirty ho.
  3. Traffic ratio: Write-back 40× kam memory-write bandwidth use karta hai.
  4. Average write latency (write-back, write-allocate), use karke:

Verify: best case ( ns, C3) aur full dirty miss ( ns, C6) ke beech hai — plausible kyunki misses rare hain (). ratio parent ke bus-utilisation derivation se exactly match karta hai. ✓


C9 — Multi-core twist: dirty data doosre core ko dikhna

Woh exam trap jahan write-back ka deferred update ek doosre CPU se milta hai.

  1. Agar B naively main memory padhta hai toh use 42 milega — stale. Yahi woh bug hai jo write-through avoid karta (memory hamesha current). Yeh step kyun? Write-back ne sachchi baat sirf A ki cache mein rakhi.
  2. Ek coherence protocol intervene karta hai: B ki read snoops, A dekhta hai ki woh dirty line own karta hai, aur A 99 cache-to-cache transfer ke zariye supply karta hai (aur aam taur par memory mein write back karta hai). Yeh step kyun? Correctness ke liye newest value chahiye; sirf A ke paas hai.
  3. Cost intuition: write-back coherence machinery (snoops, ownership states) add karta hai jise write-through partly sidestep karta hai kyunki memory authoritative hoti hai.

Verify: deliver ki gayi value 99 hai, kabhi 42 nahi. Yeh parent table ki row "Multi-core Coherence: harder for write-back" confirm karta hai. Cores mein ordering ki consistency memory consistency models se formally define hoti hai. ✓


Recall Self-test: compute karne se pehle cell ka naam batao

Write-allocate ke under write miss par ek dirty line evict hoti hai — total cost? ::: (cell C6). Write-through with buffer depth aur drain — sustained stall threshold rate? ::: (cell C2); sirf set karta hai ki burst kitni der tolerate hogi. Write-back kab write-through se haarta hai? ::: Write-once / no temporal locality (cell C7), jahan har write ek full miss hai. WB vs WT memory-write ratio aur ke saath? ::: (cell C8).