TLB (translation lookaside buffer): Question bank — Hinglish deep dive

5.4.12 · D5 · Hardware › Memory Hierarchy & Caches › TLB (translation lookaside buffer)

Recall Shuru karne se pehle — vocabulary aur symbols jo tumhare paas hone chahiye

Words:

VPN = virtual page number, virtual address ka "kaunsa page" wala hissa.
PFN = physical frame number, DRAM mein "kaunsa frame" jahan page hai.
Offset = ek page ke andar byte ki position; kabhi translate nahi hoti.
Walk = jab TLB PFN nahi jaanta tab memory mein Page Table padhna PFN dhundne ke liye.

Is page ke timing formula mein use hone wale Symbols:

$t_{TLB}$ = TLB search karne ka time (ek chota fast lookup, e.g. $\sim 1$ ns).
$t_{m}$ = ek memory (DRAM) access ka time (e.g. $\sim 100$ ns).
$W$ = ek walk mein kitne memory reads lagte hain. Single-level Page Table ko $W = 1$ read chahiye; $L$ -level table ko $W = L$ reads chahiye (x86-64 mein $L = 4$ ). Toh ek walk time mein $W \cdot t_{m}$ cost karti hai.
$h$ = TLB hit rate (fraction of accesses jo TLB mein milti hain, $0 \leq h \leq 1$ ).
EMAT = Effective Memory Access Time, hits aur misses blend karne ke baad average time per access.

Agar inme se koi bhi shaky lagta hai, pehle parent note revisit karo — traps assume karte hain ki tum inhe jaante ho.

Pehle yeh pictures dekhni hain

Neeche ke saare traps teen mental images par lean karte hain. Questions se pehle inhe dekho.

1 — Offset TLB ko bypass kyun karta hai (bit-level breakdown). Kisi bhi virtual address ko do fields mein split karo: high bits (VPN) aur low $lo g_{2} P$ bits (offset). Sirf VPN lookup hota hai; offset seedha copy ho jaata hai physical address mein.

Figure — TLB (translation lookaside buffer)

Figure dekho: left mein VPN box wahi cheez hai jo TLB mein enter hoti hai aur changed hokar nikalti hai (VPN→PFN). Offset box ek seedhi horizontal wire ki tarah draw ki gayi hai — yeh TLB ko kabhi touch nahi karti. Yahi reason hai "offset kabhi translate nahi hota": bytes apni position page ke andar maintain rakhte hain, isliye unke low bits VA aur PA mein identical hote hain.

2 — Hit path vs miss path (time kahan jaata hai). Agla figure woh do routes trace karta hai jo ek access le sakta hai. Hit par tum $t_{TLB} + t_{m}$ pay karte ho. Miss par same final data access se pehle walk $W \cdot t_{m}$ additionally pay karte ho.

3 — Size-vs-speed trade-off (kyun "bada hamesha better" galat hai). Bada, zyada-associative TLB hit rate $h$ raise karta hai lekin search time $t_{TLB}$ bhi badhata hai, aur woh search har access ke critical path par hoti hai. Agla figure EMAT ko un do opposing effects ke sum ke roop mein dikhata hai.

Formula EMAT formula kahan se aata hai ("why")

Har access chahe kuch bhi ho do kaam karta hai: TLB search karta hai ( $t_{TLB}$ ) aur eventually ek data access karta hai ( $t_{m}$ ). Sirf yeh difference hota hai ki walk bhi hogi ya nahi.

Probability $h$ se (hit): cost $= t_{TLB} + t_{m}$ .
Probability $1 - h$ se (miss): cost $= t_{TLB} + W t_{m} + t_{m}$ (extra $W t_{m}$ walk hai).

Unhe unki probabilities se blend karo — average har outcome times uski kitni baar hoti hai: $EMAT = h (t_{TLB} + t_{m}) + (1 - h) (t_{TLB} + W t_{m} + t_{m})$ Jo parts dono brackets mein hain ( $t_{TLB} + t_{m}$ ) woh $h$ chahe jo bhi ho survive karte hain, toh unhe factor out karo: $EMAT = t_{TLB} + t_{m} + (1 - h) W t_{m}$ Ise aise padho: "hamesha search + hamesha ek access + (miss fraction)×(walk cost)." Walk ek optional term hai, aur yeh exactly utni hi baar scale hota hai jitni baar tum miss karte ho.

True or false — justify karo

The TLB is a cache of translations, not of data

True. Yeh VPN→PFN mappings (aur permission bits) store karta hai, un addresses ki bytes nahi; actual data abhi bhi data Cache (memory hierarchy) ya DRAM mein hoti hai.

A TLB hit means the data you want is already in the CPU cache

False. Hit ka sirf yeh matlab hai ki translation (VPN→PFN) known hai; jo physical address yeh deta hai woh data cache mein miss kar sakta hai aur DRAM read ki zarurat pad sakti hai.

On a TLB miss the CPU must always go to disk

False. Miss ka matlab hai translation cached nahi hai, lekin page usually abhi bhi DRAM mein hota hai — tum bas Page Table walk karte ho. Sirf genuine Page Fault disk touch karta hai.

Flushing the TLB on a Context Switch is always necessary

False. Yeh tabhi zaruri hai jab entries tagged na hon. ASID/PCID tags ke saath har entry apna owning address space carry karti hai, toh different processes ki entries bina flush ke safely coexist kar sakti hain.

Increasing the page size reduces the number of TLB entries needed to cover a given amount of memory

True. Ek entry poori page cover karti hai, toh bade pages ka matlab har entry zyada bytes map karti hai — same TLB "reach" ke liye kam entries chahiye, jo effective hit rate raise karta hai.

The offset bits are the same in the virtual and physical address

True. Paging ek poori page ko ek frame mein relocate karta hai lekin bytes ko andar rearrange kabhi nahi karta, toh low

lo g_{2} P

bits translation se untouched pass hoti hain (figure 1 dekho).

A fully-associative TLB can never suffer a conflict miss

True. Koi bhi entry kisi bhi slot mein ja sakti hai, toh misses sirf capacity (ya cold/compulsory) misses hain, conflict misses nahi jo mapping collisions se hoti hain.

Doubling the TLB size always lowers effective access time

False. Bada, zyada-associative TLB

h

raise karta hai lekin

t_{TLB}

bhi raise karta hai (zyada entries parallel mein compare karni hain), aur

t_{TLB}

har access par pay hota hai. Jab added

Δ t_{TLB}

saved

(Δ h) W t_{m}

se zyada ho jaata hai, EMAT upar jaata hai — exactly woh crossover jo figure 3 mein dikhaya gaya hai.

If the hit rate

h = 1

, the walk cost disappears from EMAT

True.

EMAT = t_{TLB} + t_{m} + (1 - h) W t_{m}

mein factor

(1 - h)

0

ho jaata hai, bas TLB search plus ek data access bachta hai — koi walk kabhi pay nahi hoti.

Error dhundho

"To translate address 0x12ABC, we send all bits through the TLB."

Galat: sirf VPN (high bits) lookup hota hai. Offset 0xABC TLB ko completely bypass karta hai aur seedha physical address mein copy ho jaata hai (figure 1).

"A TLB miss and a page fault are two names for the same event."

Galat: TLB miss memory mein fast Page Table walk se resolve hoti hai; Page Fault ka matlab page resident nahi hai aur OS ko disk se laana padta hai — hazaaron guna slower.

"We form the physical address by adding the offset to the PFN."

Galat: pehle PFN ko left

lo g_{2} P

by shift karo (frame ke base byte tak pahunchne ke liye), phir offset OR karo. Plain addition un bits ko corrupt kar dega jo offset field ke saath overlap karte hain.

"After a flush the TLB immediately runs at its old hit rate."

Galat: flushed TLB cold hota hai. Agli accesses tab tak miss karti rahti hain jab tak translations refill na ho jaayein, jisse switch ke baad temporarily "miss storm" aata hai aur running slower hoti hai.

"Because the TLB is a cache, a bigger TLB is like a bigger cache — strictly better."

Galat: critical path se off bade L2/L3 data cache ke unlike, TLB har access par consult hota hai, isliye uski latency

t_{TLB}

directly throughput par tax lagaati hai. Yahan size speed ke against trade hoti hai (figure 3).

"If the OS unmaps a page, the change takes effect instantly on all cores."

Galat: doosre cores abhi bhi apne TLBs mein stale entry hold kar sakte hain. Unhe invalidate karwaane ke liye TLB shootdown (ek inter-processor interrupt) zaruri hai.

"The valid/permission bits are stored in the page table, so the TLB doesn't need them."

Galat: TLB un bits ko PFN ke saath cache karta hai taaki woh read/write/execute aur user/kernel checks bina walk ke har access par enforce kar sake.

Why questions

Why does the TLB exist at all instead of just reading the page table each time?

Kyunki page-table read DRAM mein hota hai, toh har access mein kam se kam ek extra memory read cost hota (

L

-level table ke liye

W = L

reads tak). Recent translations cache karna Locality of Reference exploit karta hai us walk ko almost hamesha skip karne ke liye.

Why does the TLB work — what property of programs makes it effective?

Locality of Reference: programs baar baar same few pages revisit karte hain, toh cached translations ka ek small set vast majority of accesses cover kar leta hai.

Why is the offset deliberately left out of the translation?

Paging whole pages ko units ke roop mein move karta hai; ek byte ki apne page ke andar position invariant hai (figure 1), toh offset translate karna redundant kaam hoga aur addressing scheme break kar dega.

Why do multi-level page tables make the TLB more valuable, not less?

L

-level table ki walk

W = L

DRAM reads cost karti hai. TLB hit par us poore chain ko avoid karta hai, toh table jitna deeper (bada

W

), utna bada penalty

(1 - h) W t_{m}

jo woh bachata hai.

Why can two processes both hold "VPN 0x5" in the TLB simultaneously without confusion?

Sirf tabhi agar entries ASID/PCID se tagged hon jo address space identify karta hai. Hardware VPN aur tag dono match karta hai, toh har process apni mapping dekhta hai.

Why does a small drop in hit rate hurt so much?

Extra cost term

(1 - h) W t_{m}

miss fraction ke saath linearly scale karta hai, aur har miss

W

memory accesses ka poora walk pay karta hai; sirf kuch percent zyada misses bhi bahut expensive walks add kar deti hain.

Why is a multi-level (L1 + L2) TLB used instead of one medium TLB?

Speed aur coverage dono paane ke liye: tiny L1 TLB zyaatar accesses ko small

t_{TLB}

ke saath answer karta hai, jabki bada slower L2 TLB L1 misses ko full page-table walk se pehle pakad leta hai — data Cache (memory hierarchy) hierarchy ko mirror karta hua.

Edge cases

What happens on the very first access to a brand-new page after boot (cold TLB)?

Yeh compulsory TLB miss hai: abhi tak kuch bhi cached nahi hai, toh walk entry fill karta hai. Kuch galat nahi — cold misses unavoidable hain aur self-correcting hain.

If the hit rate is

0

, what does EMAT reduce to?

EMAT = t_{TLB} + t_{m} + W t_{m} = t_{TLB} + (W + 1) t_{m}

: har single reference par TLB search, poora walk, aur final data access pay karte ho — worst case.

What if a TLB entry is present but its permission bit forbids the operation (e.g. writing a read-only page)?

Translation ke liye yeh hit hai lekin protection fault hai: TLB PFN supply karta hai phir bhi permission check fail hoti hai, toh hardware access complete karne ki jagah fault raise karta hai.

What happens to the TLB when the same VPN maps to a new PFN after the OS remaps it?

Purani entry ab stale hai aur use invalidate karna padega (locally, aur doosre cores par shootdown ke zariye) is se pehle ki woh galat PFN de; warna process galat frame padhta hai.

If page size

P

equals the whole address space, how many offset bits and VPN bits exist?

Saare address bits offset ban jaate hain (

lo g_{2} P

of them) aur VPN

0

bits ka hota hai — ek single "page," toh translation trivial hai aur TLB pointless hai. Ek degenerate lekin instructive limit.

What if a program's working set is larger than the TLB can hold?

TLB thrash karta hai: entries reuse se pehle evict ho jaati hain, hit rate cold case ki taraf collapse ho jaata hai, aur EMAT chad jaata hai — kisi bhi Cache (memory hierarchy) ki tarah capacity-miss failure mode.