Page tables are a fundamental component of virtual memory systems, translating virtual addresses to physical addresses. However, their memory consumption can become substantial under certain workloads, sometimes rivaling or exceeding the actual data they map. The core issue lies in how page tables scale with the number of processes sharing memory. As explained by Fernando Simões, when multiple processes map the same physical page, each process requires its own Page Table Entry (PTE) to map that page. With each PTE typically occupying 8 bytes, and a standard data page being 4 KiB (4096 bytes), the math is straightforward: 512 processes mapping the same page require 512 × 8 bytes = 4096 bytes of PTEs - exactly the size of one data page. Thus, with 512 processes sharing memory, the page table overhead equals the size of the shared data itself. This relationship becomes problematic in real-world scenarios involving extensive memory sharing. In one case, Qi Zheng observed a process with 590 GiB of resident set size (RSS) accompanied by 110 GiB of page tables, when the theoretical minimum should have been only around 1.2 GiB of PTEs. This discrepancy arose because the workload used jemalloc and tcmalloc, which return memory to the kernel via madvise(MADV_DONTNEED) rather than munmap(). While madvise(MADV_DONTNEED) frees the actual data pages and clears the PTEs, it does not free the page table structures themselves, allowing empty page tables to accumulate over time. Similar issues have been documented in database workloads. Percona reported Postgres suffering out-of-memory kills where page tables grew from 45 MiB to over 25 GiB as database backends touched more of the shared buffer cache on a 192 GB machine. ClickHouse measurements showed that with 200 connections scanning a 15.6 GiB cached table, page tables consumed 6.1 GiB of memory - reduced to just 111 MiB when huge pages were employed. The problem extends beyond simple shared memory scenarios. On Windows, Sopel noted that zombie processes may consume no actual memory but still retain at least 32 KiB of page tables each. In an extreme case involving an AMD iGPU driver bug, 100,000 exited cmd.exe processes left approximately 3.5 GiB tied up in page table structures. Mitigation techniques exist but come with trade-offs. Huge pages (such as Transparent Huge Pages) can dramatically reduce page table overhead by mapping larger memory regions with fewer entries, though they require unfragmented physical memory and can stall allocation under load. Other proposed solutions include mshare (to allow processes to share page tables) and kernel modifications to free page table structures when madvise(MADV_DONTNEED) is used - the latter approach was merged into the Linux kernel in 2025 after several revisions. Understanding page table memory consumption is crucial for system administrators and developers working with memory-intensive applications, particularly those involving shared memory or large numbers of processes, as what appears to be available memory may actually be consumed by these often-overlooked data structures.