Las tablas de páginas son un componente fundamental de los sistemas de memoria virtual, traduciendo direcciones virtuales a direcciones físicas. Sin embargo, su consumo de memoria puede volverse sustancial bajo ciertas cargas de trabajo, a veces rivalizando o superando los datos reales que mapean. El problema principal radica en cómo las tablas de páginas escalan con el número de procesos que comparten memoria. Como explicó Fernando Simões, cuando varios procesos mapean la misma página física, cada proceso necesita su propia Entrada de Tabla de Páginas (PTE) para mapear esa página. Con cada PTE ocupando típicamente 8 bytes y una página de datos estándar siendo 4 KiB (4096 bytes), el cálculo es sencillo: 512 procesos mapeando la misma página requieren 512 × 8 bytes = 4096 bytes de PTEs - exactamente el tamaño de una página de datos. De esta manera, con 512 procesos compartiendo memoria, el overhead de las tablas de páginas equivale al tamaño de los datos compartidos mismos. Esta relación se vuelve problemática en escenarios del mundo real que involucran un uso extensivo de la memoria compartida. En un caso, Qi Zheng observó un proceso con 590 GiB de tamaño de conjunto residente (RSS) acompañado de 110 GiB de tablas de páginas, cuando el mínimo teórico debería haber sido solo alrededor de 1.2 GiB de PTEs. Esta discrepancia surgió porque la carga de trabajo utilizó jemalloc y tcmalloc, que devuelven memoria al kernel mediante madvise(MADV_DONTNEED) en lugar de munmap(). Mientras que madvise(MADV_DONTNEED) libera las páginas de datos reales y borra las PTEs, no libera las estructuras de las tablas de páginas mismas, permitiendo que las tablas de páginas vacías se acumulen con el tiempo. Se han documentado problemas similares en cargas de trabajo de bases de datos. El problema se extiende más allá de los escenarios simples de memoria compartida. En Windows, Sopel señaló que los procesos zombi pueden no consumir memoria real pero aún retener al menos 32 KiB de tablas de páginas cada uno. En un caso extremo relacionado con un error del controlador de iGPU de AMD, 100,000 procesos cmd.exe salidos dejaron aproximadamente 3.5 GiB atados en estructuras de tablas de páginas. Existen técnicas de mitigación, pero conllevan compromisos. Otras soluciones propuestas incluyen mshare (para permitir que los procesos compartan tablas de páginas) y modificaciones al kernel para liberar las estructuras de las tablas de páginas cuando se utiliza madvise(MADV_DONTNEED) - este último enfoque se fusionó al kernel de Linux en 2025 después de varias revisiones. Entender el consumo de memoria de las tablas de páginas es crucial para administradores de sistemas y desarrolladores que trabajan con aplicaciones intensivas en memoria, particularmente aquellas que involucran memoria compartida o un gran número de procesos, ya que lo que parece ser memoria disponible puede estar realmente consumido por estas estructuras de datos a menudo pasadas por alto.