¿Qué CPU admiten páginas de 1 GB?

Algunas CPU Intel admiten páginas de 1GB. Esto se identifica mirando CPUID 0x80000001, EDX bit 26 . El kernel de Linux expone esto a través de /proc/cpuinfola pdpe1gbbandera .

¿Dónde descubrimos qué CPU admiten esto y cuáles no? ¿O qué línea de productos admite esta función? No hay nada en estas páginas Intel ARK que indique soporte para esta función.

CPUs que hacen de soporte páginas: 1 GB

Xeon E5620 (Westmere)
Core i5-4250U ( Haswell, móvil )

Otras CPU que no admiten páginas de 1 GB:

Xeon E5506 (Nehalem)
Core i7-2720QM (Sandy Bridge, móvil)
Core i5-2500K (Sandy Bridge)

cpu

— Jonathon Reinhart
fuente

Relacionado: ¿Cómo usar las páginas Intel Westmere 1GB en Linux?

— Jonathon Reinhart

De acuerdo con esta página :

Además de sus páginas estándar de 4 KB, los procesadores x86-64 más nuevos, como los procesadores AMD64 más nuevos de AMD y los procesadores Intel Westmere y posteriores pueden usar páginas de 1 GB en modo largo

Parece ser cierto, ya que era una nueva característica de las CPU Westmere .

— Viacheslav Rodionov
fuente

Sí, definitivamente miré todas esas páginas de Wikipedia. Sin embargo, esta respuesta no es correcta. Sandy Bridge es más nuevo que Westmere, y ahora tengo dos CPU Sandy Bridge que no lo admiten.

— Jonathon Reinhart

@JonathonReinhart: la gran desventaja de Hugepages para uso general, esp. 1G páginas, es que toda la página gigante está atando tanta RAM física. Si un proceso asigna 1GiB normalmente, solo las partes que ha tocado realmente ocupan memoria virtual. (el exceso de compromiso incluso permite asignaciones que el núcleo no tiene suficiente espacio de intercambio para manejar). Linux no puede colocar páginas enormes en el disco, incluso cuando se detiene un proceso, por lo que una asignación de página enorme fija / bloquea esa gran cantidad de memoria física.

— Peter Cordes

Hugepages 2M tienen sentido cuando no se quedará medio vacío (por ejemplo, cuando se sabe con seguridad que se va a escribir todos los 4k de la 2M de todos modos), pero la falta de paginación es un gran problema. No es una buena idea diseñar un software de uso general que funcione horriblemente mal en escritorios con memoria limitada. No creo que pueda incluso mapear un archivo en el disco con páginas enormes de 2M, pero sería una mala idea para los ejecutables porque habrá algunas páginas de 4k dentro de un bloque de 2M que no se tocarán. Estos pueden ser desalojados de la memoria caché de página (suponiendo que fueron capturados previamente), liberando RAM.

— Peter Cordes

Con las CPU actuales que tienen TLB multinivel, el tiempo total dedicado a fallas TLB probablemente no sea tan malo, ¿verdad? No he perfilado cosas grandes como Firefox. Me interesaría ver un resumen legible de cuánto tiempo pasa en las fallas de TLB, (especialmente en las caminatas de página), y cosas como las fallas de L1 I-cache. Sé que podría señalarlo perf... Incluso si quisieras usar 2M páginas enormes para Firefox, supongo que muchos de sus datos internos se asignan en fragmentos más pequeños que eso. Habría una sobrecarga para asegurarse de minimizar la fragmentación externa de las asignaciones dentro de un búfer de página enorme.

— Peter Cordes

Las fallas de TLB son costosas en operaciones de alta memoria y acceso aleatorio, como muchas aplicaciones de bases de datos. Las páginas enormes hacen una diferencia significativa, pero incluso allí, están hablando de páginas de 2 MB, no de 1 GB. El sistema operativo es el usuario más probable de páginas de 1 GB a través de la asignación directa de todo el espacio de direcciones físicas.

— GreenReaper