Abstract
Paging completely eliminates external fragmentation by dividing both virtual and physical memory into fixed-size chunks called Pages and Page Frames (typically ). The OS maintains a per-process Page Table that maps Virtual Page Numbers (VPN) to physical Page Frame Numbers (PFN). Address translation uses bitwise concatenation rather than addition, yielding fast hardware lookup.
- Category: Fixed-Size Address Translation Architecture
- Primary Unit Size: ().
- Key Advantage: Eliminates External Fragmentation entirely (all physical frames are identical in size).
Paging Architecture
In a paged system, physical memory is partitioned into fixed-sized blocks called Page Frames (PFN), and virtual memory is partitioned into identical fixed-sized blocks called Pages (VPN).

Virtual Address Structure
A Virtual Address () is split into two bitfields:
- Virtual Page Number (VPN): Indexes into the process’s Page Table.
- Offset: Identifies the exact byte location within the target page.

Because page sizes are powers of two (e.g., ), translation does not require arithmetic addition—the MMU simply concatenates the translated PFN with the original Offset.
graph TD VA["Virtual Address<br/>(VPN | Offset)"] --> Table["Page Table Lookup<br/>(Index by VPN)"] Table --> PFN["Retrieve Page Frame Number (PFN)"] PFN --> Concat["Concatenate PFN + Offset"] Concat --> PA["Physical RAM Address"]
Step-by-Step Address Translation Math
Consider a 32-bit architecture with pages:
- Page size = 12 bits reserved for the Offset (hexadecimal range
0x000to0xFFF). - Remaining upper bits = reserved for the Virtual Page Number (VPN) ( possible pages).

Example Problem
Translate Virtual Address 0x00007468 into a Physical Address given the active Page Table:

- Extract Offset: The lowest 12 bits (3 hex digits) represent the Offset:
- Extract Virtual Page Number (VPN): The remaining upper bits represent the VPN:
- Page Table Lookup: Look up entry
0x7in the process’s Page Table:
- Construct Physical Address: Concatenate PFN
0x2with Offset0x468:

Paging Trade-offs & Memory Overhead
flowchart TD TITLE["Paging Trade-offs"] subgraph ADV["<b>Advantages</b><br/><br/>• NO External Fragmentation<br/>• Simple Allocation (Free frame list)<br/>• Easy Page Swapping to Disk"] end subgraph LIM ["<b>Limitations</b><br/><br/>• Internal Fragmentation<br/>• Double Memory Access Latency<br/>• Large Page Table Overhead"] end TITLE --> ADV TITLE --> LIM classDef cellStyle font-size:15px,padding:12px; class TITLE,A,L cellStyle
Advantages
- Zero External Fragmentation: Physical RAM is allocated from a simple free list of identical fixed-size frames. Any free frame can satisfy any page request.
- Simplified Allocation & Swapping: Allocating memory or swapping unused pages to disk is fast because all chunks share identical dimensions.
Limitations & Solutions
- Internal Fragmentation: If a process requests , it receives two full pages (), leaving unused inside the second page.
- Memory Access Latency: Translating an address requires two physical memory accesses: first to read the Page Table Entry from RAM, then to read the actual target memory address.
- Solution: Translation Lookaside Buffer (TLB)—a high-speed hardware cache of recent translations inside the MMU.
- Massive Page Table Overhead: In a 32-bit system with pages, each process needs Page Table Entries. At per entry, each process consumes of RAM strictly for its Page Table!
- Solution: Hierarchical / Multilevel Page Tables.