The leftover-plank problem
In the memory rung you watched the OS act like a landlord, handing each process one contiguous block of RAM. That picture is honest but it has a wound: external fragmentation. As processes come and go, the free space shatters into a scatter of awkward gaps. You might have 100 MB free in total and still be unable to load a 40 MB process, because no single gap is 40 MB wide. It is like trying to seat a party of six in a restaurant that has eight empty chairs — but spread one-here, two-there across the room. The space exists; it just is not in one piece.
The root cause is that we let blocks be any size the process asked for. Cut planks to custom lengths and the offcuts you are left with rarely match the next order. So here is a deceptively simple question that turns out to fix everything: what if memory did not come in custom planks at all, but in identical bricks? If every piece is the same fixed size, an offcut from one process is exactly the right size for any other. That single decision is the whole heart of paging, and the rest of this rung is just working out its consequences.
Two words: pages and frames
Paging cuts the world into bricks on both sides, and gives the two sides different names so we never confuse them. Physical RAM is divided into equal-size slots called frames. A process's logical address space is divided into equal-size chunks of the same size called pages. A page and a frame are exactly the same size — a 4 KB page fits in a 4 KB frame, glove on hand. The job of paging is simply to decide which page goes into which frame, and to remember the mapping.
Here is the magic that kills fragmentation: a process's pages do NOT have to land in adjacent frames. Page 0 can live in frame 12, page 1 in frame 5, page 2 in frame 27 — scattered all over physical RAM. To the running program this is invisible; its address space still looks like one smooth, contiguous stretch. The scatter happens underneath, in physical memory, and a table will keep track of it. Because any free frame is as good as any other, the OS can load a process whenever there are enough free frames anywhere, in any order. The leftover-plank problem simply cannot occur: every brick fits every hole.
An address is really two numbers
If pages are scattered, how does an address still make sense? The trick is to read every logical address as two numbers stuck together: a page number and an offset. The page number says which page this address falls in; the offset says how far into that page it sits. Think of an address like a street address: the page number is the building, the offset is the apartment inside it. Translation only needs to figure out which physical frame the building maps to — the apartment number never changes.
The split is not arithmetic the program ever does; it falls straight out of the bits, which is why paging is fast. With a 4 KB page, the offset needs to count from 0 to 4095, and since 2^12 = 4096, that is exactly the low 12 bits of the address. Everything above those 12 bits is the page number. So on a 32-bit address the hardware just slices: the top 20 bits are the page number, the bottom 12 are the offset — no division, just wiring. Let us make it concrete with one tiny address.
Logical address = 9221, page size = 4 KB (4096 bytes) page number = 9221 / 4096 = 2 (which page) offset = 9221 % 4096 = 1029 (how far in) so 9221 == (page 2, offset 1029) If page 2 maps to frame 5: physical = 5 * 4096 + 1029 = 21509 Note: the offset 1029 is carried across UNCHANGED.
The table that remembers where each page lives
Something has to store the mapping from page numbers to frame numbers, and that something is the page table — one per process. It is exactly a book's index: look up the page number, read off the frame it really lives in. The page table is an array indexed by page number; entry 2 holds the frame for page 2, entry 3 the frame for page 3, and so on. To translate, the hardware takes the page number, looks it up in the table to get a frame, then glues that frame onto the unchanged offset to form the real physical address. The next guide builds this whole translation step by step; here we just need to know the table is the thing doing the remembering.
A program must never be allowed to set this table itself — that would let it map its pages onto another process's frames and read its secrets. So the table is the kernel's, set up in protected memory, and the hardware that does lookups is the memory management unit (MMU) sitting between the CPU and RAM. When the OS switches processes, it points the hardware at the new process's table. One special register, the page-table base register, holds the address of the current table, and changing it on a context switch is how the same logical address 9221 can mean a different physical byte for each process. Each table entry, by the way, carries more than a frame number — a valid bit, protection bits, and a dirty bit ride along too, which later guides put to work.
The catch — and why a tiny cache is coming
Paging is beautiful, but be honest about its hidden bill. The page table is too big to live in registers, so it sits in RAM. That means every single memory access a program makes now costs two memory accesses: first read the page table to find the frame, then read the actual data. We have quietly doubled the cost of touching memory — and memory was already the slow part of the machine. A naive paging design would run every program at half speed, which no one would accept.
The fix rests on a happy fact about real programs: they keep using the same few pages over and over — the page holding the loop they are running, the page holding the array they are scanning. So instead of consulting the big table in RAM every time, the hardware keeps a small, very fast cache of the most recently used (page number to frame) pairs, right next to the CPU. That cache is the translation lookaside buffer (TLB) — think sticky notes for the pages you just touched. When the page you want is on a sticky note, you skip the table read entirely and get the frame at near-zero cost; only when it is not do you pay for the full lookup.