OS & Systems Fundamentals • Memory Management & Virtual MemoryMedium⏱️ ~3 min
Page Size Trade-offs: 4 KB vs 2 MB vs 1 GB
Memory is partitioned into fixed size pages. The standard size is 4 KB, but modern CPUs also support huge pages of 2 MB and sometimes 1 GB. Choosing page size involves fundamental trade-offs between TLB efficiency, fragmentation, and operational complexity.
Larger pages dramatically reduce TLB pressure. A typical Level 1 Data TLB (DTLB) holds only 64 to 128 entries for 4 KB pages, covering just 256 KB to 512 KB of address space. With 2 MB pages, the same TLB covers 128 MB to 256 MB, a 512x improvement. For memory intensive workloads, this reduces TLB misses and page table walks, saving 5% to 20% CPU. Meta reported these gains on JVM heaps and in-memory caches, while Netflix saw single digit to low double digit percent CPU wins for long lived heap regions.
The cost is fragmentation and inflexibility. A 2 MB page consumes 2 MB of physical memory even if the application uses only a few kilobytes, wasting RAM. Paging in or out a 2 MB page means a 2 MB I/O operation, which is expensive and slow. Forming 2 MB contiguous regions requires memory compaction, which can stall the system for milliseconds. Transparent Huge Pages (THP), which automatically promote 4 KB pages to 2 MB, cause unpredictable latency spikes from background compaction and TLB shootdowns across CPUs. As a result, Meta and other latency sensitive services often disable THP entirely and use explicit huge pages only for carefully selected regions like database buffer pools.
The decision rule: use huge pages for stable, large, contiguous, hot memory regions where TLB misses dominate (large heaps, buffer pools, in-memory caches). Stick with 4 KB pages for fragmented, short lived, or latency critical workloads where compaction stalls are unacceptable. Amazon's latency sensitive services on EC2 avoid THP to prevent multi-millisecond pauses that would violate Service Level Objectives (SLOs).
💡 Key Takeaways
•TLB coverage scales with page size. A 64 entry TLB covers 256 KB with 4 KB pages, 128 MB with 2 MB pages, or 64 GB with 1 GB pages. Larger pages reduce TLB misses by 512x or more.
•TLB miss costs are 100 to 200 nanoseconds plus thousands of CPU cycles for the page table walk. For memory bound workloads exceeding TLB capacity, this overhead can consume 10% to 20% of CPU.
•Internal fragmentation wastes memory. A 2 MB page consumes 2 MB of physical RAM even if only 4 KB is used. For workloads with many small allocations, this can waste 50%+ of memory.
•Transparent Huge Pages (THP) automates promotion but causes millisecond scale stalls from background compaction and cross CPU TLB shootdowns. Meta and Netflix disable THP for latency sensitive databases to avoid p99 spikes.
•Explicit huge pages offer predictable performance. Allocate a bounded pool of 2 MB pages at boot for known hot regions (database buffer pools, JVM heaps), leaving the rest of the system on 4 KB pages.
•Meta reported 5% to 20% CPU reduction using 2 MB pages for JVM heaps and in-memory caches. Netflix saw similar gains but requires disabling THP to avoid unpredictable pauses in critical request paths.
📌 Examples
A PostgreSQL instance with a 64 GB buffer pool using 4 KB pages requires 16 million TLB entries to cover fully, but the TLB holds only 1000 to 2000 entries. With 2 MB pages, the pool needs just 32,000 entries, fitting comfortably and reducing TLB misses by over 90%.
Meta disables THP for RocksDB and MySQL instances. THP background compaction can stall for 5 to 20 milliseconds, causing p99 query latency to spike from 2 ms to 25 ms, violating SLOs.
Netflix pre allocates explicit 2 MB huge pages for long lived JVM heaps in video encoding services. The TLB hit rate improved from 85% to 98%, cutting CPU usage by 12% and saving thousands of dollars per month in compute costs.