2011-12-12 17 views
5

He estado ejecutando algunos puntos de referencia en algunos algoritmos y perfilando el uso y la eficiencia de su memoria (accesos y fallas L1/L2/TLB), y algunos de los resultados son bastante intrigantes para mí.Cuando L1 falla es muy diferente a los accesos a L2 ... ¿relacionado con TLB?

Considerando una jerarquía de caché incluido (cachés L1 y L2), debe no el número de caché L1 no alcanza coinciden con el número de caché L2 accesos? Una de las explicaciones que encuentro estaría relacionada con TLB: cuando una dirección virtual no está mapeada en TLB, el sistema omite automáticamente las búsquedas en algunos niveles de caché. ¿Esto parece legítimo?

Respuesta

6

En primer lugar, las jerarquías de caché incluidas pueden no ser tan comunes como supongo. Por ejemplo, no creo que ningún procesador Intel actual, ni Nehalem, ni Sandybridge, posiblemente Atoms, tengan un L1 incluido en el L2. (Nehalem y probablemente Sandybridge sí, sin embargo, tienen tanto L1 y L2 incluidos dentro de L3, utilizando la terminología actual de Intel, FLC y MLC en LLC.)

Pero esto no necesariamente importa. En la mayoría de las jerarquías de caché, si tiene un error de caché L1, entonces esa falla probablemente se buscará en el L2. No importa si es inclusivo o no. De lo contrario, tendría que tener algo que le dijera que los datos que le interesan (probablemente) no están en la L2, no necesita mirar. Aunque he diseñado protocolos y tipos de memoria que hacen esto, p. un tipo de memoria que se almacena solo en la L1 pero no en la L2, útil para cosas como gráficos donde se obtienen los beneficios de combinar en la L1, pero donde se escanea repetidamente en una gran matriz, por lo que el almacenamiento en la L2 no es una buena idea . No conozco a nadie que los envíe en este momento.

De todos modos, aquí hay algunas razones por las cuales el número de fallas en la caché L1 puede no ser igual al número de accesos a caché L2.

No dice en qué sistemas está trabajando - Sé que mi respuesta es aplicable a Intel x86 como Nehalem y Sandybridge, cuyo monitoreo de eventos de rendimiento EMON le permite contar cosas como caídas de caché L1 y L2, etc. . Probablemente también se aplicará a cualquier microprocesador moderno con contadores de rendimiento de hardware para fallas de caché, como las de ARM y Power.

La mayoría de los microprocesadores modernos no se detienen en la primera falla del caché, pero continúan intentando hacer un trabajo extra. Esto generalmente se llama ejecución especulativa. Además, el procesador puede estar en orden o fuera de orden, pero aunque este último le puede dar incluso mayores diferencias entre el número de fallas L1 y el número de accesos L2, no es necesario; puede obtener este comportamiento incluso en procesadores de pedidos.

Respuesta corta: muchos de estos accesos de memoria especulativa serán a la misma ubicación de memoria. Serán aplastados y combinados.

El evento de rendimiento "falta de caché L1" probablemente esté [*] contando el número de instrucciones (especulativas) que perdieron la memoria caché L1. Que luego asignan una estructura de datos de hardware, llamada en Intel un búfer de relleno, en algunos otros lugares un registro de manejo de estado de error. Las fallas de caché posteriores que se encuentren en la misma línea de caché omitirán la caché L1, pero presionarán el buffer de relleno y se aplastarán. Solo uno de ellos, generalmente el primero, se enviará al L2 y se contará como un acceso L2.)

Por cierto, puede haber un evento de rendimiento para esto: Squashed_Cache_Misses.

([*] Por cierto, cuando digo "probablemente" aquí me refiero a "En las máquinas que ayudé a diseñar". Casi definitivamente. Podría tener que verificar la definición, mirar el RTL, pero lo haría estar inmensamente sorprendido si no. Está casi garantizado.)

P. ej. imagine que está accediendo a los bytes A [0], A [1], A [2], ... A [63], A [64], ...

Si la dirección de A [0] es igual a cero módulo 64, entonces A [0]. A [63] estará en la misma línea de caché, en una máquina con líneas de caché de 64 bytes. Si el código que los usa es simple, es muy posible que todos puedan emitirse de forma especulativa. QED: 64 acceso a memoria especulativa, 64 caché L1 falla, pero solo un acceso a memoria L2.

(.. Por cierto, no esperan que las cifras sean tan limpia puede ser que consiga exactamente 64 L1 accesos por el acceso L2)

Algunos más posibilidades:

Si el número de Los accesos L2 son mayores que el número de fallas de caché L1 (casi nunca lo he visto, pero es posible) puede tener un patrón de acceso a la memoria que confunde a un captador previo de hardware. El captador previo de hardware intenta predecir qué líneas de caché van a necesitar. Si el captador previo predice mal, puede recuperar las líneas de caché que realmente no necesita. A menudo hay un rendimiento que nunca se puede contar Prefetches_from_L2 o Prefetches_from_Memory.

Algunas máquinas pueden cancelar accesos especulativos que han provocado que falte una caché L1, antes de que se envíen al L2. Sin embargo, no sé de Intel haciendo esto.

+0

acumulando: es posible que esté viendo un evento de contador de rendimiento como L1_DCACHE_MISSES_RETIRED. Es posible que las instrucciones de ruta incorrectas hayan activado los rellenos de caché L1 y/o L2, por lo que es posible que nunca vea un error de caché L2 "retirado". –

1

La política de escritura de un caché de datos determina si un hit de tienda escribe sus datos solo en ese caché (write-back o copy-back) o también en el siguiente nivel de la jerarquía del caché (write-through). Por lo tanto, una tienda que acierta en un caché L1-D de escritura simultánea, también escribe sus datos en el caché L2.

Esta podría ser otra fuente de acceso L2 que no proviene de errores de caché L1.

Cuestiones relacionadas