What are the Tradeoffs of Page Size?
Learn the tradeoffs of page size -- page table overhead vs internal fragmentation -- with examples and OS interview questions answered.
Expected Interview Answer
Choosing a larger page size reduces page table size and TLB pressure and improves transfer efficiency for large sequential reads, while choosing a smaller page size reduces internal fragmentation and gives finer-grained control over what is actually resident in memory, so there is no universally optimal page size, only a tradeoff tuned to workload characteristics.
A page table needs one entry per page, so a small page size means far more entries are needed to cover the same address space, inflating page table memory and increasing the number of TLB entries required to avoid costly walks; a large page size shrinks the table and lets the TLB cover more address space with the same number of entries, improving translation performance for workloads with large working sets. However, small pages minimize internal fragmentation, since the last partially used page of any allocation wastes at most one page’s worth of space, whereas large pages can waste substantial memory when many allocations are smaller than a full page. Small pages also allow the OS finer granularity when deciding what to evict or prefetch, since demand paging brings in only the small chunk actually needed rather than a large page that may contain mostly unused data. Modern systems often resolve this tension with multiple page sizes, offering huge pages for large, contiguous workloads like databases while keeping standard small pages as the default for general-purpose processes.
- Large pages shrink page table size and reduce TLB miss rate
- Small pages minimize internal fragmentation on partial allocations
- Small pages give finer control over demand-paging granularity
- Explains why modern OSes offer multiple page sizes (huge pages)
AI Mentor Explanation
Page size is like deciding how big a groundskeeping unit to divide the outfield into: mark it in huge blocks and you need very few block records to describe the whole ground, but even a fielder standing at the very edge of a block forces the whole block to be marked as occupied, wasting coverage. Mark it in tiny blocks and every fielder’s actual footprint is tracked precisely with almost no wasted marking, but now the record book needs thousands of tiny block entries to describe the same ground. Neither extreme is universally right; it depends on whether the ground has a few players spread wide or many players packed close together.
Step-by-Step Explanation
Step 1
Define the range
Page size is a fixed power-of-two chunk (e.g. 4KB standard, 2MB or 1GB huge pages) that the address space is divided into.
Step 2
Assess page table cost
Smaller pages need more page table entries to cover the same address space, growing table size and TLB pressure.
Step 3
Assess fragmentation cost
Larger pages waste more space per allocation whose size is not a clean multiple of the page size (internal fragmentation).
Step 4
Pick per workload
Use huge pages for large contiguous workloads (databases, in-memory caches); use standard pages as the general-purpose default.
What Interviewer Expects
- Clear tradeoff: large pages reduce page table/TLB overhead but increase fragmentation
- Understanding that small pages give finer demand-paging granularity
- Awareness of huge pages as a real-world mitigation for large workloads
- Ability to reason about which workload benefits from which page size
Common Mistakes
- Claiming one page size is universally best regardless of workload
- Confusing internal fragmentation (page size) with external fragmentation (allocation)
- Forgetting that page table size scales inversely with page size
- Not knowing huge pages exist as a practical compromise in real systems
Best Answer (HR Friendly)
“Page size is a tradeoff between two costs: bigger pages mean less bookkeeping and faster address lookups, but more wasted space when an allocation does not fill a whole page, while smaller pages waste very little space but need a lot more bookkeeping entries to track memory. Most modern systems use a small default page size for everyday programs and offer optional huge pages for big workloads like databases that want the lookup speed benefit.”
Code Example
#include <stdio.h>
int main(void) {
long address_space = 1L << 32; /* 4 GB address space */
long small_page = 4096; /* 4 KB standard page */
long huge_page = 2L * 1024 * 1024; /* 2 MB huge page */
long entries_small = address_space / small_page;
long entries_huge = address_space / huge_page;
printf("4KB pages need %ld page table entries\n", entries_small);
printf("2MB pages need %ld page table entries\n", entries_huge);
/* Fewer entries with huge pages -> smaller table, fewer TLB misses,
but a small allocation now wastes up to ~2MB of internal fragmentation. */
return 0;
}Follow-up Questions
- How do huge pages reduce TLB misses for large working sets?
- What is internal fragmentation and how does page size affect it?
- Why might a database benefit from huge pages while a shell script would not?
- How does page size interact with the cost of a page fault?
MCQ Practice
1. What happens to page table size as page size increases?
A larger page size means the same address space is covered by fewer, larger pages, so fewer page table entries are required.
2. What is the main downside of using very large page sizes?
Large pages waste more memory when an allocation is smaller than a full page, since the unused remainder of the page cannot be reclaimed -- this is internal fragmentation.
3. Why do modern operating systems offer huge pages as an option?
Huge pages are offered as an opt-in for workloads with large working sets (like databases) so they benefit from fewer TLB misses and smaller page tables, without forcing every process to accept the fragmentation cost.
Flash Cards
What does increasing page size do to page table size? — Shrinks it -- fewer, larger pages need fewer page table entries to cover the same address space.
What does increasing page size do to internal fragmentation? — Increases it -- more space is wasted when an allocation does not fill a full page.
What benefit do small pages give demand paging? — Finer granularity -- only the small chunk actually needed is loaded, not a large page of mostly unused data.
What is a huge page? — An optional, much larger page size (e.g. 2MB or 1GB) offered for workloads with large working sets to cut TLB misses.