¿En qué circunstancias se pueden producir grandes páginas de un aumento de velocidad?

Question

CPU x86 modernos tienen la capacidad de soportar los tamaños de página más grande que el legado 4K (es decir, 2 MB o 4 MB), y hay instalaciones OS ( Linux , de Windows ) para acceder a esta funcionalidad.

El enlace de Microsoft por encima de los estados grandes páginas de "aumentar la eficiencia de la memoria intermedia de traducción, lo que puede aumentar el rendimiento de la memoria de acceso frecuente". Que no es muy útil para predecir si las páginas grandes mejorarán cualquier situación dada. Estoy interesado en el hormigón, preferentemente cuantificados, ejemplos en los que el traslado de algunos lógica del programa (o toda una aplicación) para utilizar páginas grandes se ha traducido en una mejora del rendimiento. Alguien tiene alguna historia de éxito?

Hay un caso particular que sé de mí mismo : usando enorme páginas pueden de manera espectacular reducir el tiempo necesario para bifurcar un proceso grande (presumiblemente como el número de registros de la TLB que necesitan la copia se reduce por un factor del orden de 1.000). Estoy interesado en saber si enormes páginas también pueden ser un beneficio en escenarios menos exóticos.

Answer 1

He intentado idear algún código que maximizaría goleada de la TLB con 4k páginas con el fin de examinar las posibles ganancias de las grandes páginas. El material a continuación se ejecuta 2.6 veces más rápido (de páginas de 4 K) cuando las páginas se 2MByte son proporcionados por malloc de libhugetlbfs (Intel i7, 64 bits Debian Lenny); esperemos que obvio lo scoped_timer y random0n hacer.

  volatile char force_result;

  const size_t mb=512;
  const size_t stride=4096;
  std::vector<char> src(mb<<20,0xff);
  std::vector<size_t> idx;
  for (size_t i=0;i<src.size();i+=stride) idx.push_back(i);
  random0n r0n(/*seed=*/23);
  std::random_shuffle(idx.begin(),idx.end(),r0n);

  {
    scoped_timer t
      ("TLB thrash random",mb/static_cast<float>(stride),"MegaAccess");
    char hash=0;
    for (size_t i=0;i<idx.size();++i) 
      hash=(hash^src[idx[i]]);
    force_result=hash;
  }

Una versión más simple "línea recta" con sólo hash=hash^src[i] sólo ganó el 16% de las grandes páginas, pero (especulación) fantasía obtención previa de hardware puede estar ayudando el caso 4K cuando los accesos son predecibles (supongo que podría desactivar la obtención previa para investigar si eso es cierto).

Answer 2

La mayor diferencia en el rendimiento vendrá cuando usted está haciendo accesos aleatorios ampliamente espaciados a una región grande de la memoria - donde los "grandes" significa mucho más grande que el rango que se pueden asignar por todas las pequeñas entradas de página en la TLB (que por lo general tienen múltiples niveles en los procesadores modernos).

Para hacer las cosas más complejas, el número de elementos de TLB de páginas de 4 KB suele ser mayor que el número de entradas para las páginas de 2MB, pero esto varía mucho por el procesador. También hay una gran cantidad de variación en la forma están disponibles en el Nivel 2 TLB muchas entradas "gran página".

Por ejemplo, en un sistema de 10h AMD Opteron Familia Revisión D ( "Estambul"), cpuid informes:

• L1 DTLB: páginas de 4 KB: 48 entradas; páginas 2MB: 48 entradas; páginas 1 GB: 48 entradas
• L2 TLB: páginas de 4 KB: 512 entradas; 2MB páginas: 128 entradas; páginas 1 GB: 16 entradas

Mientras que en un sistema Intel Xeon 56xx ( "Westmere"), cpuid informes:

• L1 DTLB: páginas de 4 KB: 64 entradas; 2MB páginas: 32 entradas
• L2 TLB: páginas de 4 KB: 512 entradas; páginas 2 MB: ninguno

Ambos pueden asignar 2 MB (512 * 4kB) usando pequeñas páginas antes de nivel de sufrimiento 2 fallos TLB, mientras que el sistema de Westmere puede mapear 64MB usando sus 32 entradas 2MB TLB y el sistema de AMD puede mapear 352MB utilizando las 176 entradas 2MB TLB en su L1 y L2 TLB. Ambos sistemas de obtener una aceleración significativa mediante el uso de páginas grandes para accesos aleatorios en rangos de memoria que son mucho más grandes que 2 MB y menos de 64 MB. El sistema de AMD debe seguir mostrando un buen rendimiento usando páginas grandes para los rangos de memoria mucho más grandes.

Lo que estamos tratando de evitar en todos estos casos es el peor de los casos (nota 1) escenario de atravesar los cuatro niveles de la traducción de direcciones jerárquica x86_64.
Si ninguno de los mecanismos de caché de traducción de direcciones (nota 2) de trabajo, se requiere:

• 5 viajes a la memoria a cargar datos mapeados en una página de 4 KB,
• 4 viajes a la memoria a los datos de carga asignada en una página de 2MB, y
• 3 viajes a la memoria a cargar datos mapeados en una página de 1 GB.

En cada caso, el último viaje a la memoria es obtener los datos solicitados, mientras que los otros viajes son necesarios para obtener las diferentes partes de la información de la página de traducción. La mejor descripción que he visto es en la Sección 5.3 de AMD "Arquitectura AMD64 del programador Manual Volumen 2: Sistema de Programación" (publicación 24593) http://support.amd.com/us/Embedded_TechDocs/24593.pdf

Nota 1: Las cifras anteriores no son realmente el peor caso. Ejecuta en una máquina virtual empeora estos números. Correr en un ambiente que hace que la memoria que contiene los distintos niveles de las tablas de páginas para obtener intercambiada con el disco hace que el rendimiento más peor.

Nota 2: Por desgracia, aún sabiendo este nivel de detalle no es suficiente, ya que todos los procesadores modernos tienen cachés adicionales para los niveles superiores de la jerarquía de páginas de traducción. Por lo que yo puedo decir estos son muy pobremente documentada en público.

Answer 3

he visto mejora en algunos escenarios HPC / GRID - específicamente paquetes de física con muy, muy grandes modelos en máquinas con montones y montones de RAM. También el proceso que se ejecuta el modelo era el único activo en la máquina. Sospecho, aunque no han medido, que ciertas funciones de base de datos (por ejemplo, las importaciones a granel) se beneficiarían también.

En lo personal, creo que a menos que tenga un perfil muy bien perfilado / entendido memoria de acceso y lo hace un montón de gran acceso a la memoria, es poco probable que va a ver ninguna mejora significativa.

Answer 4

Esto se está poniendo esotérica, pero las páginas TLB Enormes hacer una diferencia significativa en la arquitectura Intel Xeon Phi (MIC) al hacer transferencias de memoria DMA (de anfitrión para la phi a través de PCIe). Este enlace Intel describe cómo habilitar páginas grandes . Encontré aumento del tamaño de transferencia de DMA más allá de 8 MB con tamaño de página TLB normal (4K) comenzado a rendimiento disminución, de aproximadamente 3 GB / s a ??menos de 1 Gb / s una vez que el tamaño de transferencia golpeado 512 MB.

Después de habilitar páginas TLB enormes (2MB), la velocidad de datos siguió aumentando a lo largo de 5 Gb / s para las transferencias de DMA de 512 MB.

Answer 5

Me conseguir un aumento de velocidad ~ 5% en servidores con una gran cantidad de memoria (> = 64 GB) que se ejecutan los procesos grandes. p.ej. para un proceso java 16GB, que es 4 x 4 KB páginas pero sólo 4k x 4 MB páginas.