Memory management is how the operating system decides where each process lives in physical memory and how a program's addresses get mapped to real hardware locations. Get the mapping right and many processes share one memory safely; get it wrong and you waste memory to fragmentation or crash into another process. This topic is a reliable source of numerical questions, and almost all of them come down to one skill: translating a logical address into a physical one. Let us build up to that.
Why memory management is hard: contiguous allocation and fragmentation
The simplest scheme gives each process one contiguous block of physical memory. It is easy to translate addresses, but it fragments badly.
External fragmentation happens when free memory exists but is split into small scattered holes, none big enough for the next process even though their total is. Compaction can fix it by shuffling processes together, but that is expensive.
Internal fragmentation happens when a process is given a slightly larger fixed block than it needs, and the leftover inside the block is wasted.
Paging exists to kill external fragmentation outright, by dropping the requirement that a process occupy one contiguous block.
Paging: page tables, frames and address translation
Paging splits the logical address space into fixed-size pages and physical memory into frames of the same size. A process's pages can sit in any free frames, in any order. A per-process page table records which frame holds each page.
A logical address is split into two parts. The high bits are the page number, an index into the page table; the low bits are the offset within the page. Because pages and frames are the same size, the offset is copied straight through to the physical address, and only the page number is translated.
Work a concrete example. Let the page size be 4 KB, which is 4096 bytes, so the offset is 12 bits. Suppose this page table:
Page | Frame |
|---|---|
0 | 8 |
1 | 3 |
2 | 5 |
3 | 9 |
Translate logical address 8196.
Page number is 8196 divided by 4096, which is 2. Offset is 8196 minus 2 times 4096, which is 4.
Page 2 maps to frame 5 in the table.
Physical address is frame times page size plus offset: 5 times 4096 plus 4, which is 20484.

That is the entire mechanism. Every paging numerical is a variation on this split-lookup-combine procedure.
The TLB: making translation fast
Every memory access now needs a page-table lookup, and the page table itself lives in memory, so a naive scheme doubles memory traffic. The translation lookaside buffer, or TLB, is a small fast cache of recent page-to-frame mappings. On a TLB hit the frame is found immediately; on a TLB miss the system reads the page table in memory and then loads the mapping into the TLB. The effective access time is a weighted average of the hit and miss paths, and computing it from a hit ratio is a standard exam question.
Multilevel page tables
A flat page table for a large address space is itself huge. A 32-bit space with 4 KB pages needs 2 to the power 20 entries per process, most of them unused. Multilevel paging pages the page table itself: an outer table points to inner tables, and only the inner tables you actually use are kept in memory. A two-level scheme splits the page number into an outer index and an inner index, at the cost of one extra memory lookup per translation. This is why the TLB matters so much.
Segmentation vs paging
Segmentation divides a program by its logical structure rather than fixed size: a code segment, a stack segment, a data segment, each of variable length. An address is a segment number plus an offset, and a segment table stores each segment's base and limit.
Paging | Segmentation | |
|---|---|---|
Division | Fixed-size pages | Variable-size logical segments |
Visible to programmer | No | Yes |
Fragmentation | Internal | External |
Address form | Page number + offset | Segment number + offset |
Paging removes external fragmentation but has no relation to program meaning; segmentation matches program structure but brings external fragmentation back. Real systems often combine them as segmented paging, paging each segment so segments stay meaningful while frames stay fixed.
Where this stops and computer architecture begins
There is a neighbouring topic that looks similar and is easy to confuse. This post is about the OS side: page tables, the TLB, and how a logical address becomes a physical one. The hardware view of memory as a speed-and-cost hierarchy, with caches and the demand-paging behaviour of virtual memory, sits in computer organisation. Keep the boundary clean, and read them together where they meet.
How this is tested in GATE
Memory Management has over 220 published questions in the KnowledgeGate bank, part of the close-to-2,000 Operating Systems total. GATE overwhelmingly tests the numerical: given a page size and a logical address, find the physical address; given a hit ratio and access times, find the effective memory access time; given an address-space and page size, find the page-table size or the number of bits in each field. Conceptual questions ask you to compare paging and segmentation or to name which fragmentation each one causes. All of it follows from the translation mechanism above.
The short version
A logical address is a page number plus an offset. Translate the page number through the page table to a frame, carry the offset through unchanged, and combine. Paging fixes external fragmentation, segmentation matches program structure, and the TLB is what keeps translation fast. Hand-solve two or three translation problems and the numericals stop being scary.
Practise translations on the memory management learn module, then drill our operating systems memory management and paging MCQs.
For the hardware-side view of caches and virtual memory, read our memory hierarchy and virtual memory deep-dive and note the boundary above.
The full syllabus in order lives in GATE Guidance by Sanchit Sir, and more explainers on the CS Fundamentals category.




