A process allocates a 16 KiB buffer and sees one continuous virtual range:

Physical memory does not need one continuous 16 KiB hole for that buffer. The operating system can divide it into four 4 KiB pieces and place those pieces in four available physical locations:

The process still sees consecutive addresses. Moving from virtual address 0x4fff to 0x5000 works even though physical frame 12 is not adjacent to physical frame 3.

This fixed-size division of virtual and physical memory is called paging.

Paging divides virtual memory into pages and physical memory into equal-sized frames, then maps each virtual page independently to a physical frame.

Paging is the dominant memory-management model in modern general-purpose operating systems. It makes noncontiguous physical allocation practical while giving processes contiguous, protected virtual address ranges.

A page is a fixed-size unit of a virtual address space. A page frame, usually shortened to frame, is an equally sized unit of physical memory.

If the system uses 4 KiB pages, every virtual page covers 4 KiB and every physical frame can hold 4 KiB:

Page and frame numbers begin at zero in this conceptual model. The address range for virtual page N is:

The end is exclusive. With a 4 KiB page size:

A page is not a copy of a frame and the terms are not interchangeable. The page belongs to a process's virtual address space. The frame belongs to the machine's physical memory. A mapping connects them.

For a page whose contents are currently in RAM:

Different virtual pages can map to different frames in any available order. A page can also be unmapped, in which case the process has no valid access to that virtual range.

Variable-size physical allocation fails when free memory is split into holes that are each too small for a large contiguous request. Paging changes the requirement.

Suppose a process needs 16 KiB and the page size is 4 KiB. It needs four frames. The operating system can use any four available frames:

No frame needs to be adjacent to another. A collection of scattered free frames is sufficient because the process sees virtual adjacency instead of physical adjacency.

This removes external fragmentation from ordinary frame allocation. Every free frame has the same size, so any free frame can hold any virtual page.

Paging does not remove every memory-management constraint. The operating system still needs enough free frames in total. Some hardware operations can specifically require physically contiguous memory. Internal waste can also occur when a requested virtual range does not fill its final page.

The important change is:

Each process needs a record of where its virtual pages lead. This mapping is represented by a page table.

Conceptually, a page table is indexed by virtual page number:

Each record is a page-table entry, or PTE. A PTE contains the physical frame number when an accessible frame is associated with the page, plus control information needed by the hardware and operating system.

Common control information describes whether the entry can currently be used and whether reading, writing, execution, or user-mode access is permitted. Hardware architectures can provide additional status and control bits.

The table above means:

The page table contains mapping metadata, not the process's actual instructions or data. The bytes live in physical frames. The page table tells the memory-management hardware which frame to use for a virtual page and what operations to allow.

The operating system constructs and updates page tables. The MMU uses the active process's page-table information while translating memory accesses.

Paging interprets a virtual address as:

The virtual page number, or VPN, identifies which page contains the address. The page offset identifies the exact byte within that page.

For virtual address VA:

Integer division is used. Consider a 1 KiB page size and virtual address 3500:

The address identifies byte 428 within virtual page 3.

Suppose the active page table maps virtual page 3 to physical frame 9:

The physical address is:

The page number changes from virtual page 3 to physical frame 9. The offset remains 428.

The offset is preserved because pages and frames have the same size. Only the identity of the containing unit changes.

Modern systems use page sizes that are powers of two, such as:

This makes the page-number and offset split line up with bit boundaries.

With 4 KiB pages, the lower 12 address bits represent the offset because 12 bits can select any byte from 0 through 4095:

For a 32-bit virtual address:

The hardware can separate the fields using bit operations rather than general division:

The mask 0xfff contains 12 one-bits:

After the page table supplies the physical frame number:

These formulas generalize to a page size of 2^k bytes:

Power-of-two sizing also guarantees that page and frame boundaries are naturally aligned. A 4 KiB page begins at an address whose lower 12 bits are zero.

Assume:

The lower three hexadecimal digits contain 12 bits because each hexadecimal digit represents four bits:

Suppose the page table contains:

For a read, the permission check succeeds. Replace the virtual page number with the physical frame number and preserve the offset:

The translation can be visualized as:

Only the top half changes. The offset is copied through untouched, which is why the physical address is 0x07f02abc and why page size determines how many bits stay fixed.

If the instruction attempted a write and the PTE were read-only, the physical frame number alone would not make the access valid. Translation includes the permission check.

For a resident, permitted page, a paging-based translation follows this conceptual sequence:

Real processors optimize this path heavily because translation is needed for instruction fetches, loads, and stores. The conceptual result does not change: the virtual page selects a mapping, and the offset selects a byte within the mapped frame.

If no usable entry exists or the permissions reject the operation, the MMU cannot produce an ordinary permitted physical access. The processor raises an exception so the operating system can interpret the condition. That exception is called a page fault. A page fault is a control transfer, not a physical frame or a page-table entry.

Paging makes permissions apply at page granularity.

A process might have:

Each page-table entry supplies the relevant permissions for its virtual page. This allows neighboring pages to have different roles even when their addresses are consecutive.

Page granularity creates a boundary that software must respect. If a 4 KiB page contains two small objects, the MMU does not assign separate permissions to each object. Both bytes are governed by the same page mapping.

Conversely, changing protection for one byte normally affects the page containing that byte. Operating-system interfaces that change memory protection therefore operate on page-aligned ranges, even if a language runtime presents a higher-level abstraction.

An inaccessible page can serve as a guard region next to a thread stack. If stack growth crosses into the guard page, the access is rejected at a predictable boundary instead of immediately modifying an adjacent valid region.

Per-page protection is powerful, but it is not object-level memory safety. An array overrun that remains within the same writable page can still corrupt another object.

Each process has its own virtual-to-physical mappings. The same virtual page number can therefore map to different frames:

If both processes access virtual address 0x5120 with 4 KiB pages:

Their physical results differ:

This is how equal pointer values remain private. The active page table is part of the process's address-space context.

Threads in one process share the process page table. They can therefore access the same virtual pages and physical frames. Each thread normally has its own stack pages, but those pages still belong to the shared process address space.

The operating system selects the appropriate address-space context when switching between processes. User-mode code cannot select another process's page table or edit entries to grant itself access.

Paging does not require every mapping to use a unique physical frame.

The operating system can map virtual pages from multiple processes to the same frame:

The two virtual page numbers do not need to match. Each process can place the shared content wherever a suitable virtual range is available.

Shared read-only frames are straightforward: both processes may read or execute the same bytes, and neither may modify them. This is useful for executable and library code.

Writable shared frames allow processes to observe each other's changes. The mappings must be established deliberately, and the processes must coordinate concurrent access just as threads coordinate access to shared variables.

The permissions can differ by mapping. Process A could receive a read-and-write mapping of a frame while Process B receives a read-only mapping of the same frame. Physical identity and virtual permissions are separate properties.

This gives paging a many-to-many relationship:

Paging changes fragmentation rather than eliminating it.

External fragmentation

At the frame-allocation layer, physical memory is divided into equal-sized units. A free frame can satisfy any one-page request. The system does not need to search for a variable-sized physical hole for an ordinary virtual region.

For example, four scattered free frames can back four consecutive virtual pages. Paging therefore eliminates external fragmentation for allocations made in whole frames.

This statement has a boundary. Components that request several physically adjacent frames can still encounter a physical-contiguity problem. Allocators inside a process can also suffer external fragmentation within their own virtual arenas.

Internal fragmentation

A virtual region's size may not be an exact multiple of the page size. The final page then contains unused space.

Suppose a region needs 10 KiB and pages are 4 KiB:

The unused tail lies inside an allocated final page, so it is internal fragmentation at the paging layer.

Under a simplified assumption that region endings are uniformly distributed within a page, the average unused tail is approximately half a page. Real waste depends on region sizes, how allocations are grouped, and whether the final frame holds other useful data managed by a lower-level allocator.

Page size affects memory waste, mapping overhead, and the amount of memory covered by each translation.

Smaller pages provide finer granularity. A small region wastes less space in its final page, permissions can be applied to smaller ranges, and a program can use a small part of a large region without necessarily involving large physical units.

The cost is that the same virtual range contains more pages. Mapping a 1 GiB range requires:

More pages require more mapping entries and more bookkeeping.

Larger pages reduce the number of entries and let one translation cover more neighboring bytes. They can be effective for large, densely accessed regions.

Their cost is coarser granularity. A small allocation can waste more of its final page, changing protection affects a larger range, and accessing a few bytes can cause a larger physical unit to be associated with the region.

There is no universally best size:

Many architectures support a normal base page size plus one or more larger page sizes for selected mappings. The operating system chooses among the supported options according to policy and workload needs.

Paging avoids the need for physically contiguous process allocations, but it introduces mapping metadata.

With a 32-bit virtual address and 4 KiB pages:

A simple flat page table with one 4-byte entry for every possible page would require:

That is substantial for a process that uses only a few virtual regions. A wider virtual address space makes a fully allocated flat table even less practical.

Real systems organize page tables so that unused portions of a sparse address space do not require one enormous flat array of entries. Regardless of organization, the conceptual lookup remains:

Page-table memory is kernel-managed overhead. It does not hold the application bytes, but it consumes real memory so the hardware can locate and protect those bytes.

On Linux and many Unix-like systems, getconf reports the normal page size:

A common result on x86-64 Linux is:

Do not hard-code that value into portable software. Other systems and architectures can use a different base page size.

A C program can query it with sysconf():

Given an address represented as an unsigned integer, the containing page begins at:

For a 4 KiB page and address 0x7f12345a:

The process can observe its virtual address and page offset. Ordinary user code does not learn the physical frame merely from that calculation.

An application that requests 24 bytes does not normally receive a dedicated 4 KiB page.

Language runtimes and memory allocators obtain larger virtual regions and divide them into smaller objects:

All four regions sit inside one writable virtual page. The kernel's protection granularity is the whole page, so it cannot treat the metadata differently from the objects around it.

The MMU sees one page with one set of hardware permissions. The allocator sees several objects, their sizes, and which portions are free.

This distinction explains why paging cannot detect most object-level bugs. If Object A overruns into Object B within the same writable page, the MMU sees a permitted write to a mapped page. It does not know where one object ends.

It also explains why freeing one small object does not unmap a page or immediately return a frame to the operating system. The allocator may retain that space for another object, and other live objects may still occupy the same page.

Paging is the operating system and hardware's fixed-size mapping mechanism. malloc(), garbage-collected heaps, and language object allocators are higher-level memory managers built on virtual regions.

Paging divides a process's virtual address space into fixed-size pages and physical memory into equal-size frames. A page table maps virtual page numbers to physical frame numbers and records the permissions and state needed to control each page.

A virtual address consists of a virtual page number and an offset. The page number selects a mapping; the resulting physical frame number replaces it; and the offset remains unchanged. Power-of-two page sizes make this split a direct bit operation.

Because pages are mapped independently, consecutive virtual pages can use scattered physical frames. This eliminates external fragmentation for ordinary frame allocation, supports per-page protection and sharing, and preserves a contiguous process view. The tradeoffs are internal fragmentation in partially used pages, page-table memory, and granularity choices determined by page size.