5.4.11 · D5 · HinglishMemory Hierarchy & Caches
Question bank — Virtual memory and paging
5.4.11 · D5· Hardware › Memory Hierarchy & Caches › Virtual memory and paging
Ye bank in boundaries ko drill karta hai: "not in RAM" ke signs, illusion aur hardware ke beech ka fark, aur woh jagahein jahan neat page-arithmetic almost-lekin-bilkul-nahi toot ti. Kisi bhi answer ke mechanics ke liye dekho Multi-level page tables, Page replacement algorithms, aur Locality of reference.
True or false — justify karo
Har answer explain karta hai kyun, kyunki akela "true/false" kuch nahi sikhata.
True or false: Virtual address ka offset part page table dwara translate hota hai.
False — sirf VPN translate hota hai. Ek page ko frame mein move karna ek rigid shift hai, isliye page ka byte frame ka byte hi rehta hai; offset unchanged copy ho jaata hai.
True or false: Page fault ka matlab hamesha yeh hai ki program mein koi bug hai.
False — page fault ek normal event hai jiska matlab hai ki page abhi disk par hai ya abhi allocate nahi hua. OS use load karta hai aur instruction resume karta hai. Sirf genuinely invalid address ka access crash (segfault) hota hai.
True or false: Process A mein virtual address 0x4000 aur Process B mein 0x4000 same physical RAM byte refer karte hain.
False — har process ka apna page table hota hai, isliye same VA alag frames pe map hoti hai. Yahi alag-alag hona woh isolation hai jo virtual memory promise karta hai.
True or false: TLB memory se actual data store karta hai.
False — TLB translations store karta hai (VPN → PFN), data nahi. Data caching ka kaam CPU caches ka hai; dono alag structures hain jo alag lookups serve karte hain.
True or false: Bade pages strictly better hote hain kyunki page table shrink ho jaata hai.
False — bade pages matlab kam entries lekin zyada internal fragmentation (1-byte ki zaroorat bhi poora page burn kar deti hai) aur har fault par heavy disk I/O. Yeh ek trade-off hai, free win nahi.
True or false: 100% TLB hit ratio ke saath, koi bhi page-table walk kabhi nahi hota.
True steady state mein — lekin har page ka pehla access (compulsory miss) TLB populate karne ke liye table walk zaroor karta hai, isliye real 100% asymptotic hai, pehle instruction se kabhi nahi.
True or false: Virtual memory ko function karne ke liye disk (swap space) chahiye hi.
False — translation aur isolation ke benefits purely RAM mein kaam karte hain. Disk sirf "pretend karo ki RAM badi hai" wale benefit ke liye chahiye; swap disabled system bhi protection ke liye paging use karta hai.
True or false: Page size programmer apne har process ke liye choose karta hai.
False — page size ek fixed hardware/OS property hoti hai (jaise 4 KiB). Koi process apni nahi chun sakta; zyada se zyada OS huge pages ek alag opt-in mechanism ke taur par offer kar sakta hai.
Galti dhundho
Neeche har statement mein ek subtle galti hai — use name karo.
"Translate karne ke liye, MMU poore virtual address ko frame number se multiply karta hai."
Galat — MMU sirf VPN ko table lookup ke zariye translate karta hai, phir karta hai. Poore address ki koi multiplication nahi hoti, aur frame number table se aata hai, VA par arithmetic se nahi.
"48-bit address space ke liye single-level page table theek hai; sirf kuch hazaar entries hain."
Galat — entries hoti hain, toh ke saath yeh entries (billions) hain, isliye Multi-level page tables exist karte hain taaki sirf used portions allocate ho sakein.
"TLB isliye help karta hai kyunki yeh memory ko faster banata hai."
Galat — TLB RAM ko speed up nahi karta. Yeh page table padhne ke liye zaruri extra memory access hata deta hai, locality ko exploit karte hue taaki translation almost free ho.
"Agar page RAM mein hai, toh use access karne par phir bhi page fault aa sakta hai."
Galat in general — agar page present hai aur permissions access allow karti hain, toh koi fault fire nahi hoga. (Ek protection fault alag trap hai, permission violation se trigger hota hai, absence se nahi.)
"TLB miss par CPU turant give up karke page fault raise karta hai."
Galat — TLB miss sirf page-table walk trigger karta hai. Page fault tabhi hota hai jab woh walk find kare ki page resident nahi hai. Miss ≠ fault.
"Kyunki har process ka apna page table hai, do processes ke beech memory share karna impossible hai."
Galat — do page tables alag VPNs (ya same VPN) ko same physical frame pe map kar sakte hain, alag tables rakhte hue shared memory de sakte hain.
Why questions
Memory ko fixed-size pages mein kyun split kiya jaata hai, arbitrary-length regions ki jagah?
Fixed sizes allow karti hain ki koi bhi page kisi bhi frame mein fit ho sake (no external fragmentation) aur translation ko ek simple shift/mask tak reduce karte hain, region ke liye start+length store karne ki jagah.
Address ke neeche ke bits kabhi translate kyun nahi hote?
Ye bits ek page ke andar ek byte ko index karte hain, aur page apna internal layout frame mein move hone par maintain karta hai. Sirf kaun sa page (base) badalta hai, isliye sirf high bits (VPN) map hote hain.
Effective access time formula mein sirf add kyun hota hai, koi bada penalty nahi?
Kyunki ek extra table-walk access ka miss penalty chhoti miss probability se weight hota hai; high locality ke saath zyaatar accesses walk skip karte hain, isliye average extra cost tiny hoti hai.
Do processes dono "address 0 se start" kaise kar sakte hain bina collide kiye?
Address 0 ek virtual address hai, aur har process ka page table uska virtual 0 alag physical frame pe map karta hai — numbers coincide karte hain lekin real locations nahi.
OS kabhi kabhi deliberately page fault kyun trigger karta hai (lazy allocation)?
OS ek page ko not-present mark kar sakta hai taaki pehla touch trap kare, use frame sirf tab allocate/zero karne deta hai jab actually use ho — RAM bachata hai un pages ke liye jo program kabhi nahi padhta.
Edge cases
Kya hota hai jab virtual address offset 0 hota hai (page ka pehla byte)?
Kuch special nahi — offset matlab VA translation ke baad frame ke base byte pe land karta hai. Arithmetic phir bhi valid hai; yeh koi degenerate ya forbidden case nahi.
Agar requested VPN ka koi valid page-table entry hi nahi hai toh kya hoga?
Lookup ek invalid (not-present-aur-not-swapped) entry find karta hai, toh OS ise illegal access treat karta hai — segfault — recoverable page fault ki jagah.
Kya hota hai agar naya page load karna ho aur physical RAM bilkul full ho?
OS ko ek resident page replacement policy use karke evict karna padta hai, agar dirty ho toh disk par likhke, incoming page ke liye freed frame occupy karne se pehle.
Degenerate case: page size poore virtual address space ke barabar (ek page).
Tab VPN ke bits hain aur sab kuch offset hai — translate karne ke liye kuch nahi, isliye paging direct addressing mein collapse ho jaati hai. Yeh limiting boundary hai jo dikhata hai ki paging tabhi payoff deta hai jab bahut saare pages hon.
Page boundary par exactly land karte address aur do pages cross karne wale access ke baare mein kya?
Boundary par ek single byte theek hai, lekin boundary cross karne wala multi-byte access do VPNs touch karta hai, dono alag translate hote hain — isliye ek half resident ho sakta hai jabki doosra fault kare.
Agar TLB aur page table disagree karein (stale TLB entry OS ke page remap karne ke baad), toh kya toot ta hai?
CPU stale frame use karke galat memory padh lega; isliye OS ko flush/invalidate karna chahiye affected TLB entry ko jab bhi woh koi mapping change kare.
Zero-size process (abhi tak koi pages mapped nahi): uska page table kaisa dikhta hai?
Saari entries invalid/not-present hain. Koi bhi access turant fault karta hai — bilkul consistent, kyunki ek brand-new process ki mappings lazily first touch par create hoti hain.
Recall Quick self-test — answers cover karo
- Kya TLB miss aur page fault same hain? ⟶ Nahi; miss se walk hota hai, fault tabhi jab page absent ho.
- Kya offset translate hota hai? ⟶ Nahi; sirf VPN.
- Kya do processes ek frame share kar sakte hain? ⟶ Haan; dono ke tables uski taraf point kar sakte hain.
- Remap par TLB flush kyun karein? ⟶ Stale, ab-galat translation use karne se bachne ke liye.