Paging vs segmentation in memory management

One divides memory by fixed size, the other by logical meaning.

Model answer.

Paging

• Virtual memory is split into fixed-size pages (commonly 4 KB) and physical memory into frames of the same size.
• A page table maps each virtual page number to a frame number; the offset within the page is copied unchanged.
• Any free frame can hold any page, so there is no external fragmentation.
• The last page of a region may be partly unused, causing internal fragmentation (on average about half a page per region).
• It is invisible to the programmer — the program just sees a flat address space.

Segmentation

• Memory is divided into variable-sized segments that match logical units: code, data, heap, stack.
• A logical address is (segment number, offset); the segment table holds a base and a limit for each segment, and the hardware checks offset < limit.
• Because segments vary in size, free memory gets broken into holes that may be too small to use: external fragmentation. Compaction can fix it but is expensive.
• Protection and sharing are natural per segment (e.g. mark the code segment read-only and share it).

Why paging dominates

• Fixed-size allocation is simple and fast; free frames can be tracked with a list or bitmap.
• It enables demand paging and swapping individual pages to disk.
• Protection bits (read/write/execute) can be set per page, giving most of segmentation's benefits.
• On x86-64, segmentation is largely disabled in 64-bit mode (a flat model), and paging does the real work.

Some older systems combined both (segmentation with paging), where each segment is itself paged, removing external fragmentation while keeping logical segments.

Common follow-up: "How does the CPU avoid a slow page-table lookup on every access?" Answer: the TLB, a small cache of recent page-to-frame translations; a TLB hit avoids walking the page table in memory.