Top 25 OS Paging and Segmentation Interview Questions (2026)

Last Updated: June 2026 | Level: Beginner to Advanced | Format: Q&A with Calculations and Diagrams

Paging and segmentation form the core of virtual memory, and address calculation questions appear in written rounds at Infosys, TCS, Wipro, and in system-level interviews at product companies. Candidates report that physical address derivation from logical addresses using page tables is a standard numerical in campus placement written tests. According to public preparation resources and candidate-reported accounts, two-level paging memory savings calculations appear frequently at GATE and MNC written assessments. This guide covers 25 focused questions with worked examples, comparison tables, and design rationale.

---

Table of Contents

1. Paging Fundamentals (Q1-Q10)
2. Segmentation (Q11-Q16)
3. Combined and Advanced (Q17-Q25)

---

Paging Fundamentals

Q1. What is paging? State its key properties. Easy

Paging is a memory management scheme that:

• Divides logical (virtual) address space into fixed-size blocks called pages.
• Divides physical memory into fixed-size blocks called frames.
• Page size = Frame size (typically 4KB).
• The OS maps each logical page to any available physical frame using a page table.

Key properties:

Property	Detail
No external fragmentation	Any frame can hold any page; no need for contiguous physical allocation
Internal fragmentation	Last page of a process may not be full; average waste = page_size / 2
Transparent to programmer	Programs use logical addresses; hardware+OS handle translation
Protection	Each page table entry has protection bits (R/W/X/user/supervisor)
Sharing	Multiple processes' page tables can point to the same physical frame

---

Q2. How do you calculate the number of bits for page number and page offset? Easy

Given:
  Logical address size = n bits
  Page size = 2^k bytes

Then:
  Page offset bits = k
  Page number bits = n - k
  Number of pages in virtual address space = 2^(n-k)

Example 1: 32-bit address, 4KB (2^12) pages

Offset bits = 12
Page number bits = 32 - 12 = 20
Number of pages = 2^20 = 1,048,576 pages

Example 2: 32-bit address, 8KB (2^13) pages

Offset bits = 13
Page number bits = 32 - 13 = 19
Number of pages = 2^19 = 524,288 pages

Example 3: 64-bit address, 4KB pages

Offset bits = 12
Page number bits = 64 - 12 = 52 (theoretical; modern x86-64 uses 48 bits)

---

Q3. Work through a complete address translation example. Medium

Given:

Page size = 1KB (2^10 bytes)
Logical address size = 16 bits
Page table:
  Page 0 -> Frame 5
  Page 1 -> Frame 2
  Page 2 -> Frame 8
  Page 3 -> Frame 1

Translate logical address: 0x2200 (decimal: 8704)

Step 1: Determine bit split

Page size = 1KB = 2^10 -> offset bits = 10
Page number bits = 16 - 10 = 6

Step 2: Split address

0x2200 in binary = 0010 0010 0000 0000
                   [6-bit page][10-bit offset]
                   = 001000 | 1000000000
Page number = 001000 (binary) = 8 (decimal)
Offset      = 1000000000 (binary) = 512 (decimal)

Wait: page table only has pages 0-3. Page 8 is not mapped -> page fault.

Try logical address 0x0A04 (decimal: 2564):

0x0A04 in binary = 0000 1010 0000 0100
Page number = 000010 = 2
Offset      = 1000000100 = 516

Frame for page 2 = 8
Physical address = 8 * 1024 + 516 = 8192 + 516 = 8708 = 0x2204

---

Q4. What determines the page table size? Calculate for a given system. Medium

Page table size = (number of pages) * (size of each PTE)

Number of pages = virtual address space / page size = 2^(address_bits) / page_size

PTE size: typically 4 bytes (32-bit system) or 8 bytes (64-bit system)

Example 1: 32-bit system, 4KB pages, 4-byte PTE

Number of pages = 2^32 / 2^12 = 2^20 = 1,048,576
Page table size = 1,048,576 * 4 = 4MB per process

With 100 processes: 400MB just for page tables. Impractical.
Solution: multi-level paging.

Example 2: 64-bit system, 4KB pages, 8-byte PTE

Number of pages = 2^64 / 2^12 = 2^52
Flat page table = 2^52 * 8 = 2^55 bytes = 32 petabytes per process
Clearly impossible. Must use multi-level paging.
x86-64 uses 4-level paging with 48-bit effective addresses.

---

Q5. Explain two-level paging. How does it save memory? Medium

Two-level paging adds a level of indirection: instead of one big page table, use a page directory pointing to smaller page tables.

Address structure (32-bit, 4KB pages):

[10 bits outer index][10 bits inner index][12 bits offset]
     |                     |
     v                     v
Outer page table      Inner page table
(1024 entries, 4KB)   (1024 entries, 4KB each)
                       Only inner tables for used regions are allocated

Memory savings:

One-level: Always 4MB per process

Two-level:
  Outer table: always present, 4KB
  Inner tables: only for regions actually used
  
A process using first 4MB of address space:
  Outer table: 4KB (1 entry pointing to inner table)
  Inner table for first 4MB: 4KB
  Total: 8KB (vs. 4MB one-level)
  
A process using code + stack (1MB each, far apart in address space):
  Outer table: 4KB
  2 inner tables: 8KB
  Total: 12KB (vs. 4MB)

Translation:

VA: [outer=5][inner=300][offset=100]
1. Outer page table[5] -> base address of inner table A
2. Inner table A[300] -> frame number F
3. Physical = F * 4096 + 100

---

Q6. How does four-level paging work in x86-64? Hard

x86-64 uses a 48-bit effective virtual address with 4-level paging (5-level paging added in newer hardware for 57-bit addresses):

Virtual address (48-bit effective):
[9 bits L4][9 bits L3][9 bits L2][9 bits L1][12 bits offset]
   PML4       PDPT        PD         PT        page offset

Each level table: 512 entries * 8 bytes = 4KB (exactly one page)

Translation flow:

CR3 register -> PML4 (Page Map Level 4) base address
  PML4[L4_index] -> PDPT (Page Directory Pointer Table) base
    PDPT[L3_index] -> PD (Page Directory) base
      PD[L2_index] -> PT (Page Table) base
        PT[L1_index] -> Physical Frame Number
          Physical address = PFN * 4096 + offset

Memory for page tables in x86-64:

• Each level is exactly one 4KB page if that region is used.
• A process using 16KB of code requires only: PML4 + PDPT + PD + 1 PT = 4 pages = 16KB for page tables.
• Deep nesting means 4 memory accesses per virtual-to-physical translation (TLB eliminates this in the common case).

Huge pages (2MB, 1GB) skip levels:

• 2MB pages: PD entry directly points to 2MB physical region (skip PT level).
• 1GB pages: PDPT entry directly points to 1GB physical region (skip PD and PT levels).

---

Q7. What is an inverted page table? Hard

Inverted page table: Instead of one entry per virtual page per process (which scales with virtual address space), have one entry per physical frame.

Inverted page table: indexed by physical frame number
Entry for frame i: (process_id, virtual_page_number) of the page occupying frame i

Size: proportional to physical RAM, not virtual address space.
For 4GB RAM, 4KB pages: 2^20 = 1M entries.
At 8 bytes per entry: 8MB total (shared by ALL processes).
vs. 4MB per process in single-level paging.

Lookup: To translate (pid, vpage) -> frame:

Must search the inverted table for the entry matching (pid, vpage).
Linear search: O(n) where n = number of physical frames (slow!).
Solution: hash table on (pid, vpage) for O(1) average lookup.
But hash collisions require chaining, and each chain entry needs a hardware walk.

Tradeoff:

• Memory efficient (one global table, not per-process).
• Lookup is harder (need hash + chaining).
• Sharing: tricky (multiple virtual pages mapped to same frame need multiple entries).

Used in: IBM System/38, PowerPC, some RISC architectures. Not used in x86 hardware (which uses hierarchical page tables).

---

Q8. What is a hashed page table? Hard

Hashed page table: Virtual page number is hashed to an index in a hash table. Each bucket contains a chain of (virtual_page, frame, next_pointer) entries.

Lookup algorithm:
1. hash(virtual_page_number) -> bucket index
2. Walk the chain in that bucket to find entry matching virtual_page
3. Return frame number if found; page fault if not found

Entry structure per chain node:
  [virtual_page | frame_number | next_pointer]

Advantage over inverted table: Only allocated for pages actually mapped (no entry for unmapped virtual pages). Good for sparse address spaces (64-bit processes that use a tiny fraction of their virtual space).

Clustered page table: Variant where each hash entry maps a cluster of several consecutive pages (e.g., 16 pages per entry). Reduces table size and improves locality for sequential access patterns.

---

Q9. Explain how the TLB interacts with a two-level page table on a TLB miss. Medium

TLB miss handling (hardware page walk on x86):

1. CPU generates virtual address
2. MMU checks TLB: miss
3. Hardware page walker (not OS) reads CR3 -> PML4 base (in practice, 4-level on x86-64)
4. Page walker reads PML4[L4_index] from RAM (1 memory access)
5. Reads PDPT[L3_index] (1 memory access)
6. Reads PD[L2_index] (1 memory access)
7. Reads PT[L1_index] (1 memory access)
8. Physical address = frame_number + offset
9. TLB entry updated with (virtual_page -> frame)
10. Memory access proceeds

Total on TLB miss with 4-level paging: 4 extra memory accesses.

Software TLB (MIPS, some RISC): On TLB miss, hardware raises a software exception. OS TLB miss handler does the page walk and loads the TLB entry manually. More flexible but adds OS interrupt overhead per miss.

x86 hardware page walker: No OS involvement on TLB miss. Hardware does the walk transparently. OS is only involved for page faults (page not present in RAM).

---

Q10. Calculate effective memory access time with a two-level paging and TLB. Hard

Given:

TLB lookup time: 10ns (hardware cache)
RAM access time: 100ns
TLB hit ratio: 0.95
Two-level page table in RAM (2 extra RAM accesses on TLB miss)

EAT calculation:

Case 1: TLB hit (probability 0.95)
  Total = TLB_lookup + 1 RAM access
        = 10 + 100 = 110ns

Case 2: TLB miss (probability 0.05)
  Total = TLB_lookup + 2 page table accesses + 1 data access
        = 10 + 2*100 + 100 = 310ns

EAT = 0.95 * 110 + 0.05 * 310
    = 104.5 + 15.5
    = 120ns

Without TLB, with two-level paging:
  Every access: 2 page table lookups + 1 data = 3 * 100 = 300ns

TLB speedup: 300 / 120 = 2.5x faster

---

Segmentation

Q11. What is segmentation? How does it work? Easy

Segmentation divides a program's logical address space into logical units called segments, each with a different size.

Segments correspond to the program's logical structure:

Segment 0: Code segment (program text)
Segment 1: Data segment (global variables)
Segment 2: Stack segment
Segment 3: Heap segment
Segment 4: Shared library segment

Logical address structure:

<segment_number, offset>

Segment table: Each entry has:

Entry: [base | limit | protection_bits]
  base  : physical address where segment starts
  limit : length of segment
  protection: read/write/execute permissions

Translation:

1. CPU generates <segment_num, offset>
2. Check: offset < limit[segment_num]? If not: segmentation fault
3. Physical address = base[segment_num] + offset

---

Q12. How does address translation work in segmentation? Show an example. Medium

Segment table:

Segment | Base   | Limit
   0    | 1400   | 1000  (code: 1400-2399)
   1    | 6300   | 400   (data: 6300-6699)
   2    | 4700   | 1100  (stack: 4700-5799)

Translation examples:

Logical <0, 430>:
  Check: 430 < limit[0]=1000? YES
  Physical = 1400 + 430 = 1830  [VALID]

Logical <1, 10>:
  Check: 10 < limit[1]=400? YES
  Physical = 6300 + 10 = 6310  [VALID]

Logical <0, 1500>:
  Check: 1500 < limit[0]=1000? NO (1500 >= 1000)
  SEGMENTATION FAULT

Logical <3, 100>:
  Segment 3 not in table -> INVALID SEGMENT fault

---

Q13. What are the advantages and disadvantages of segmentation? Easy

Advantages:

Advantage	Detail
No internal fragmentation	Segment is exactly the size of the logical unit
Logical protection	Code segment: read+execute only. Data segment: read+write. Easy per-segment protection.
Sharing	Two processes can share a code segment (point to same base address) without sharing data
Flexible growth	Stack and heap segments can grow independently
Programmer visibility	Programmer can use segment IDs explicitly (in systems that expose them)

Disadvantages:

Disadvantage	Detail
External fragmentation	Variable-size segments leave holes in physical memory after allocation/deallocation
Contiguous allocation required	Each segment must be in contiguous physical memory
Compaction needed	To reclaim fragmented holes; expensive
Maximum segment size limit	Segment must fit in physical memory (no virtual memory extension without combining with paging)

---

Q14. How does segmentation handle sharing between processes? Medium

Two processes can share a code segment by having their segment tables point to the same physical base address.

Process P1 segment table:
  Segment 0 (code): base=4000, limit=5000

Process P2 segment table:
  Segment 0 (code): base=4000, limit=5000  <- same physical pages

  Segment 1 (data): base=10000, limit=2000  <- different from P1's data

Both P1 and P2 see their own segment number 0 but it maps to the same physical memory. The code is read+execute only, so neither can corrupt it.

Shared libraries in modern OSes: Shared libraries (libc.so, libstdc++.so) are memory-mapped using mmap() and the underlying pages are shared across all processes using that library. This is segmentation-like sharing implemented via paging.

---

Q15. What is the difference between base-limit registers and segmentation? Easy

Aspect	Base-Limit Registers	Segmentation
Segments per process	One (entire process)	Multiple (code, data, stack, heap...)
Protection granularity	Entire process	Per-segment
Sharing	Not possible without overlap	Possible (share specific segments)
Overflow detection	Limit register check	Per-segment limit check
Hardware	One pair of registers	Segment descriptor table + register per segment

Base-limit is the simplest form of memory protection. Segmentation generalizes it to multiple regions per process with independent base and limit values and separate protection bits.

---

Q16. What causes a segmentation fault and what happens when it occurs? Easy

A segmentation fault (segfault) occurs when a process accesses memory outside its valid segments or violates segment permissions.

Common causes:

1. Null pointer dereference: Access at address 0, which is not mapped.
2. Buffer overflow: Writing past the end of a stack array overflows into another region.
3. Use after free: Accessing memory after it has been released (pointer to freed heap).
4. Stack overflow: Recursion grows stack past its limit into another segment.
5. Writing to read-only memory: Writing to a const data section or code segment.

What happens:

1. MMU detects: offset >= limit (or access violates protection bits)
2. Hardware raises protection fault interrupt
3. OS signal handler invoked: sends SIGSEGV to the process
4. Default SIGSEGV handler: terminate process with core dump

In C/C++: Segmentation fault (core dumped) message. The core dump contains the program state at crash for debugging with gdb.

---

Combined and Advanced

Q17. What is segmented paging? How does address translation work? Hard

Segmented paging combines both: logical address space is divided into segments, and each segment is paged.

Logical address structure:

<segment_number | page_number | offset>

Translation:

1. Segment table[segment_number] -> base address of that segment's page table + limit
2. Check: (page_number * page_size + offset) < segment_limit? If not: fault.
3. Segment's page table[page_number] -> frame_number
4. Physical address = frame_number * page_size + offset

Advantages:

• Logical structure from segmentation (code/data/stack separate with different protections).
• Physical allocation benefits from paging (no external fragmentation).

Used in: Intel x86 (IA-32) hardware fully supports this model. Linux sets segment bases to 0 and limits to 4GB (flat model), essentially reducing to pure paging.

---

Q18. What are huge pages (2MB, 1GB) and how do they change address translation? Hard

Standard 4KB pages (x86-64, 4-level paging):

[9-bit PML4][9-bit PDPT][9-bit PD][9-bit PT][12-bit offset]
All 4 levels needed.

2MB huge pages (x86-64):

[9-bit PML4][9-bit PDPT][9-bit PD][21-bit offset]
PD entry has "Page Size" bit set = 1, points directly to 2MB frame.
PT level is skipped.

1GB huge pages (x86-64):

[9-bit PML4][9-bit PDPT][30-bit offset]
PDPT entry has "Page Size" bit set = 1, points to 1GB frame.
PD and PT levels skipped.

TLB impact:

• 2MB page: 1 TLB entry covers 512x more than a 4KB page.
• 1GB page: 1 TLB entry covers 262,144x more than a 4KB page.
• A database with a 32GB buffer pool using 1GB huge pages needs only 32 TLB entries. With 4KB pages, it needs 8 million TLB entries (impossible; TLB typically has 64-4096 entries).

---

Q19. How does the OS handle copy-on-write at the page table level? Hard

After fork():

Parent page table:                Child page table (copy):
Page 0 -> Frame 10 (R/W) [SHARED] Page 0 -> Frame 10 (R/W) [SHARED]
Page 1 -> Frame 11 (R/W) [SHARED] Page 1 -> Frame 11 (R/W) [SHARED]
...                                ...
Both entries marked COPY-ON-WRITE (write protection enabled in hardware)

When parent writes to Page 0:

1. Hardware: write to Frame 10, but page is write-protected -> PROTECTION FAULT
2. OS CoW handler:
   a. Allocate new Frame 20
   b. Copy Frame 10 contents to Frame 20
   c. Update parent's page table: Page 0 -> Frame 20 (R/W, no longer CoW)
   d. Frame 10 reference count = 1 (only child). Mark child's Page 0 writable.
3. Parent's write proceeds to Frame 20.
4. Child still has Page 0 -> Frame 10 (original, unchanged).

Reference counting on frames: Each physical frame has a reference count. CoW shares increase refcount. A write decrements the shared refcount and creates a private copy. Only when refcount reaches 1 is the page no longer shared.

---

Q20. What is the relationship between page size and TLB effectiveness? Medium

TLB coverage = TLB entries * page size

Page size	TLB entries	Coverage
4KB	64	256KB
4KB	4096	16MB
2MB	64	128MB
1GB	64	64GB

Larger pages = more coverage with fewer TLB entries.

Larger page tradeoffs:

• Internal fragmentation increases (a 1MB file in a 1GB page wastes ~1GB-1MB).
• Not suitable for small, numerous allocations.
• Optimal only for large, long-lived, contiguous allocations (database buffer pools, large JVM heaps, GPU memory).

OS policy: Most OSes use 4KB as the default. Applications that benefit from huge pages must explicitly request them (mmap with MAP_HUGETLB on Linux, or use Transparent Huge Pages).

---

Q21. What is a shared memory segment and how is it implemented via paging? Medium

Shared memory allows two or more processes to communicate by accessing the same physical memory region.

Implementation via paging:

Process P1 page table:
  Page 7 -> Frame 50  (private)
  Page 8 -> Frame 200 (SHARED)
  Page 9 -> Frame 201 (SHARED)

Process P2 page table:
  Page 3 -> Frame 200 (SHARED -- same physical frame as P1's page 8)
  Page 4 -> Frame 201 (SHARED -- same physical frame as P1's page 9)
  Page 5 -> Frame 80  (private)

Both processes see the shared region at different virtual addresses, but reads/writes go to the same physical frames.

In Linux:

// Process 1: create shared memory
int shmid = shmget(IPC_PRIVATE, 4096, IPC_CREAT | 0666);
char *ptr = shmat(shmid, NULL, 0);
strcpy(ptr, "Hello from P1");

// Process 2: attach the same shared memory
char *ptr = shmat(shmid, NULL, 0);
printf("%s\n", ptr);  // Prints "Hello from P1"

Synchronization: Shared memory provides no synchronization. Use semaphores or mutexes to coordinate access.

---

Q22. How does mmap() use page tables? Hard

mmap() creates a new mapping in the virtual address space by modifying the process's page table.

File-backed mmap:

fd = open("bigfile.dat", O_RDWR);
ptr = mmap(NULL, length, PROT_READ|PROT_WRITE, MAP_SHARED, fd, offset);

What happens:

1. OS reserves a range of virtual pages for the mapping.
2. Page table entries for those virtual pages are initially invalid (not present).
3. On first access to any page: page fault -> OS reads the corresponding file block into a free frame, updates PTE.
4. Access proceeds.
5. On munmap() or process exit: dirty pages are written back to the file.

Shared file mmap: Multiple processes mmap the same file. OS maps them to the same physical frames (the page cache). Writes by one process are immediately visible to others.

Anonymous mmap (MAP_ANONYMOUS): Used for large heap allocations (glibc malloc uses mmap for allocations > 128KB). No file backing; pages are zero-initialized on first access (demand zeroing).

---

Q23. What is a guard page and how does it prevent stack overflow? Medium

A guard page is a virtual memory page at the end of the stack region that is intentionally left unmapped (no physical frame assigned, marked as invalid in the page table).

Stack layout in virtual memory:
[Stack limit - guard page (unmapped)]
[Stack region (valid pages)]
[...current stack pointer...]

Stack overflow detection: When a stack grows past its limit and touches the guard page:

1. CPU tries to access the guard page virtual address
2. Page table entry: valid = 0 (intentionally)
3. Hardware raises page fault
4. OS page fault handler checks: "Is this address in the guard page region?"
   YES -> send SIGSEGV to process (stack overflow)
   NO  -> normal page fault handling

Without guard pages: Stack overflow would silently overwrite adjacent memory (heap data, other segments), causing corruption with no immediate indication. Guard pages provide fail-fast detection.

Linux: Each thread stack has a guard page. The main thread's guard page is at the bottom of the stack. POSIX pthread_attr_setguardsize() controls guard page size for created threads.

---

Q24. What are the access rights bits in a page table entry and how are they enforced? Medium

Standard page table entry protection bits (x86-64):

Bit	Name	Effect
P (bit 0)	Present	0 = page not in RAM, trigger page fault
R/W (bit 1)	Read/Write	0 = read-only, 1 = writable
U/S (bit 2)	User/Supervisor	0 = kernel-only, 1 = user accessible
PWT (bit 3)	Write-Through	Cache write-through for this page
PCD (bit 4)	Cache Disable	Bypass CPU cache
A (bit 5)	Accessed	Set by hardware on read or write
D (bit 6)	Dirty	Set by hardware on write
NX (bit 63)	No Execute	1 = page cannot be executed (data pages)

Enforcement:

• R/W = 0, attempt to write -> protection fault -> SIGSEGV.
• U/S = 0, user-mode access -> protection fault -> SIGSEGV.
• NX = 1, attempt to execute instructions from this page -> protection fault -> SIGSEGV.

NX bit use (security): Stack and heap pages have NX=1 in modern OSes. This prevents attackers from injecting shellcode onto the stack and executing it (W^X: Write XOR Execute policy). Code pages have NX=0 but R/W=0.

---

Q25. How does an OS implement demand zeroing? Hard

Demand zeroing is the OS technique of presenting freshly-allocated pages as all-zeros without actually zeroing them at allocation time.

Implementation:

1. A single physical zero page is maintained by the OS, filled with all zeros, mapped as read-only.
2. When a process requests new memory (e.g., via anonymous mmap or BSS section), all new page table entries point to the shared zero page, marked copy-on-write, read-only.
3. If the process only reads these pages: they all read zeros from the single shared zero page. No physical memory allocated.
4. When the process writes to one of these pages:
   • Write protection fault triggered.
   • OS allocates a new physical frame.
   • Copies the zero page content (all zeros) to new frame.
   • Updates the PTE to point to the new frame, marked writable.
   • Write proceeds.

Why this matters:

A process with a 1GB BSS section (zero-initialized global data):
  Without demand zeroing: OS must zero 1GB of RAM at process startup.
  With demand zeroing:    OS maps all 1GB to the zero page. Startup is instant.
  Physical RAM is allocated only when pages are actually written.

This is critical for large processes (databases, JVMs) that declare large memory regions but only use a fraction at any time.

---

FAQ

Q: Which causes more fragmentation: paging or segmentation? Paging causes internal fragmentation (partial last page). Segmentation causes external fragmentation (variable-size holes between segments). Paging's internal fragmentation is bounded (maximum half a page per process) and is generally preferable to external fragmentation.

Q: Can a page be larger than a segment? Yes, but it is unusual. If a segment is smaller than the page size, the page holding that segment has internal fragmentation equal to (page_size - segment_size). Modern combined systems handle this by making segment sizes multiples of the page size.

Q: How many page table levels does ARM64 use? ARM64 (ARMv8+) supports up to 4-level paging (similar to x86-64). The number of levels and translation granule (4KB/16KB/64KB pages) is configurable.

---

Related PapersAdda guides:

• OS Memory Management Questions 2026
• OS Interview Questions 2026
• OS Threads and Concurrency Questions 2026
• OS Process Scheduling Questions 2026
• DBMS Interview Questions 2026