estudio, an alisis y modelado de memorias cach e...

Estudio, Analisis y Modelado deMemorias Cache CompartidasBajo Administracion Dinamica

Tesis de Grado en Ingenierıa Informatica

Alumno:Carballal Abarzua Claudio

Director:Dr. Ing. Jose Luis Hamkalo

Facultad de IngenierıaUniversidad de Buenos Aires

Mayo de 2011

You can’t always get what you want.But if you try sometime,

you just might find,you get what you need.

The Rolling Stones, 1968.

Resumen

Los desarrollos de las arquitecturas multi-nucleo o Chip Multi-Processors(CMP) marcaron una mejora notable en el desempeno de las aplicaciones, yaque proporcionan una manera eficiente de ejecutar multiples de estas, o a unamisma (a traves de diferentes subtareas) en forma simultanea. Esta mejora enla eficiencia de la ejecucion se logra al contar con multiples unidades de proce-samiento individuales que tienen disponibles recursos de memoria privados ycompartidos. En la actualidad, algunas arquitecturas de procesadores cuentancon multiples niveles de memoria cache. Por simplicidad y desempeno, algunosniveles se mantienen como privados para cada nucleo de un procesador, mientrasque otras arquitecturas exploran compartir el ultimo nivel de memoria cache en-tre diferentes nucleos del mismo procesador.

Las memorias cache compartidas aportan grandes beneficios al desempeno,ya que en el caso extremo de un solo nucleo en ejecucion con los demas sin activi-dad, el proceso ejecutandose, dispondrıa de toda la memoria cache compartidaque es de mayor tamano que las usadas como privadas para cada nucleo. Aunque,debido a este mayor tamano, posee una mayor latencia la cual es propagada alos niveles superiores de la jerarquıa.

Por otro lado, la polıtica de reemplazo LRU comunmente utilizada en lasmemorias cache, no distingue entre los diferentes procesos y su distinta localidadde datos a lo largo de su ejecucion, lo cual aumenta la congestion al aumentar lacantidad de procesos en ejecucion simultanea. La ausencia de aislamiento y ad-ministracion en el uso del espacio en memoria cache resulta en una degradaciondel desempeno de los procesos en ejecucion. Por estos motivos se hace nece-sario proponer polıticas de administracion de los recursos a fin de minimizar losefectos antes descriptos.

En la busqueda por lograr este objetivo, en la primera parte de esta tesis seanaliza el estado del arte en la administracion dinamica de memorias cache y sepresenta una herramienta publica y de codigo abierto, que permite capturar yprocesar al vuelo, mediante modulos intercambiables, las instrucciones de multi-ples procesos en ejecucion simultanea. Esta herramienta utiliza el frameworkPIN para realizar la instrumentacion dinamica de los procesos ejecutados y unControlador de Procesos que administra la ejecucion paso a paso de estos yenvıa la informacion recolectada a los modulos de procesamiento.

En la siguiente parte, se presenta una nueva polıtica de administraciondinamica, que busca mejorar el desempeno global de las aplicaciones utilizandouna metrica para medir la necesidad del espacio ocupado por cada proceso enla memoria cache compartida, utilizando la clasificacion de desaciertos D3C.

i

Se finaliza con el analisis de los resultados obtenidos, al simular con la he-rramienta previamente presentada, un grupo seleccionado de benchmarks de laSPEC CPU 2006 agrupados como conjuntos de prueba. Este analisis final, tieneen cuenta las metricas de la tasa de desaciertos, el IPC y el ancho de bandalogrado por la nueva polıtica de administracion presentada aquı, comparadacon la polıtica de administracion Capitalista, utilizada como referencia en lostrabajos relacionados.

Se concluye que la polıtica de administracion desarrollada logra una menortasa de desaciertos en la memoria cache de tipo compartido en forma globalpara cada conjunto de prueba estudiado. Ciertos procesos ven incrementadasu tasa de desaciertos por una restriccion del espacio otorgado, para que otrosprocesos hagan un mejor uso de ese espacio, logrando aumentar el IPC enforma global. Asimismo, se pudo mostrar que se hace un uso mas eficiente delespacio en la memoria cache compartida, eliminando los desaciertos de tipointer-procesos y adaptando, a una velocidad suficiente, el espacio disponible enfuncion de la localidad de datos para cada proceso en ejecucion. El ancho debanda utilizado por cada conjunto de prueba evaluado, se ve reducido por lamejor administracion del espacio. El efecto final observado, es una disminuciondel ancho de banda utilizado en un valor similar a la reduccion del valor de latasa de desaciertos global en la memoria cache compartida.

ii

Abstract

Multi-Core architectures or Chip Multi-Processors (CMP) developments pro-ved to be a remarkable improvement in applications performance, as they pro-vide an efficient way to run multiple applications, or just one (through differentsubtasks) simultaneously. This improvement in execution efficiency is achievedby multiple individual processing units with private and shared memory re-sources available. For the sake of simplicity and performance, some levels arekept private for each processor core, while other architectures explore sharingthe last level of cache among different cores of the processor.

Shared caches memories are highly beneficial to performance, because in theextreme case of a single core active while others inactive, the process beingexecuted would count with all shared cache memory, which is larger than allthose used as private memories for each core. However, due to its increased size,has a higher latency which is propagated to superior levels of the hierarchy.

On the other hand, the LRU replacement policy commonly used in the cachememories, does not distinguish between different processes and the different da-ta locality along they execution, which increases congestion by increasing thenumber of processes running simultaneously. The absence of isolation and man-agement in the use of cache memory space results in a performance degradationof every executing process. For this reason, it is desirable to grant to each pro-cess in execution an amount of shared cache memory so as to achieve the bestpossible performance without causing an efficiency decrease of other processesthat are also in progress.

When searching to achieve this goal, in the first part of this thesis the stateof the art of dynamic administration of cache memories is analized and a newfree and open-source tool was introduced to capture and process, on the fly,instructions from multiple processes being executed simultaneously by usinginterchangeable modules. This tool uses the PIN framework to dynamicallyinstrument executed processes and a process Controller to manage a step bystep execution, and to send the collected information to the processing modules.

In the next part a new dynamic management policy developed is introduced,which main objective is to improve the applications global performance by usinga metric based on the D3C miss classification, so as to measure and manage thespace needed for each process in shared cache memories.

iii

Finally, it is presented the analysis of the results obtained from simulatinga selected group of benchmarks from the SPEC CPU 2006 grouped as test sets.This final analysis takes into account the shared cache miss rate, the IPC andthe bandwidth used by the new management policy presented here, and it iscompared with Capitalist management policy, used as reference in other relatedworks.

It was observed that the proposed policy has a lower miss rate in globalshared cache for each test set studied. Certain processes increased their missrates by space restrictions, so that other processes could make better use of thatspace, thus increasing the global IPC. Also, it was proved that a more efficientuse of space in shared cache memory is achieved by eliminating inter-processmisses and adapting available space for each process in progress at a suitablespeed according to the hit rate to shared cache memory. Finally, the bandwidthconsumed for each policy was analyzed and it is concluded that when makingbetter management of space in shared cache memories, misses are reduced, andtherefore the accesses to the main memory, thus diminishing bandwidth use,according to the reduction in the global miss rate.

iv

Agradecimientos

Deseo agradecer a mis padres, Claudio y Marıa Teresa, por el esfuerzo querealizaron en mi educacion. Porque siempre se hicieron sentir cerca, a pesar deestar lejos. Por mostrarme que el mundo es mucho mas grande e interesante delo que uno piensa y vale la pena conocerlo.

A mi tutor en esta tesis, el Dr. Jose Luis Hamkalo, por confiar en mi trabajo,motivarme a investigar y a dar mucho mas de mi mismo.

A todas las personas que viven en mi Neuquen natal y que siguen presentesen mi dıa a dıa.

Claudio Carballal Abarzua.

Mayo de 2011.

Acerca del autor

Claudio Carballal Abarzua nacio en la ciudad de Neuquen, provincia delmismo nombre, el dıa 25 de Septiembre de 1981.

Llevo a cabo sus estudios primarios en la escuela Paula Albarracın de Sarmien-to N°101, junto con el estudio del idioma ingles en el Instituto Oxford, ambosen la misma localidad.

Los dos primeros anos del nivel secundario los realizo en la Escuela Provincialde Ensenanza Tecnica N°5, finalizando sus estudios en la Escuela Nacional deEnsenanza Tecnica N°2 tambien de la ciudad de Neuquen.

Ya en los primeros anos del nivel secundario se decidio por realizar los estu-dios de ingenierıa en informatica en la ciudad de Buenos Aires, donde actual-mente es estudiante de la carrera Ing. en Informatica siendo a la vez docentedel departamento de Electronica en la Facultad de Ingenierıa de la Universidadde Buenos Aires.

Indice General

Resumen I

Abstract III

Agradecimientos V

Acerca del autor VI

1. Introduccion 11.1. Motivaciones de la Tesis . . . . . . . . . . . . . . . . . . . . . . . 11.2. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1. Memorias cache Privadas y Compartidas . . . . . . . . . . 21.2.2. Clasificacion de desaciertos . . . . . . . . . . . . . . . . . 41.2.3. Jerarquıas de memorias . . . . . . . . . . . . . . . . . . . 51.2.4. Administracion de memorias cache compartidas . . . . . . 61.2.5. Metodologıas utilizadas para el analisis . . . . . . . . . . 71.2.6. Instrumentacion de binarios ejecutables . . . . . . . . . . 81.2.7. Herramientas desarrolladas . . . . . . . . . . . . . . . . . 8

1.3. Objetivos de la tesis . . . . . . . . . . . . . . . . . . . . . . . . . 91.4. Organizacion de los capıtulos y secciones . . . . . . . . . . . . . . 9

2. Ambiente de desarrollo 102.1. El framework PIN . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.1. Comportamiento en tiempo de ejecucion . . . . . . . . . . 122.1.2. Diferencias de PIN con el framework Valgrind . . . . . . . 12

2.2. Ambiente de desarrollo creado . . . . . . . . . . . . . . . . . . . . 142.2.1. Pintool de Instrumentacion y Controlador de Procesos . . 152.2.2. Modulo 1: Recoleccion de trazas . . . . . . . . . . . . . . 182.2.3. Modulo 2: Simulador de jerarquıas de memorias cache . . 20

2.3. Validacion del entorno de desarrollo . . . . . . . . . . . . . . . . 212.3.1. Modelo del lazo simple . . . . . . . . . . . . . . . . . . . . 212.3.2. Desarrollo de pruebas unitarias . . . . . . . . . . . . . . . 222.3.3. Pruebas unitarias . . . . . . . . . . . . . . . . . . . . . . . 22

3. Administracion dinamica dememorias cache compartidas 243.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2. Trabajo Relacionado . . . . . . . . . . . . . . . . . . . . . . . . . 243.3. Polıtica de administracion . . . . . . . . . . . . . . . . . . . . . . 27

3.3.1. Clasificacion de desaciertos D3C . . . . . . . . . . . . . . 273.3.2. Distancia de Pila LRU . . . . . . . . . . . . . . . . . . . . 283.3.3. Metrica para la evaluacion de la equidad de rendimiento . 293.3.4. Heurıstica de administracion dinamica propuesta . . . . . 33

4. Ambiente de Simulacion 354.1. Simulador de Jerarquıas de

Memoria Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.1.1. Componentes de Hardware simulados . . . . . . . . . . . 35

i

4.2. Aspectos de la implementacionde componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2.1. Tinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2.2. LRU Stack . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2.3. Page Coloring y Hashing de direcciones . . . . . . . . . . 394.2.4. Arquitectura simulada . . . . . . . . . . . . . . . . . . . . 40

4.3. Seleccion de los benchmarksa utilizar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.3.1. Gcc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.3.2. Libquantum . . . . . . . . . . . . . . . . . . . . . . . . . . 434.3.3. H.264 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.4. Clasificacion como conjuntosde prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.4.1. Conjunto A - H.264, Libquantum . . . . . . . . . . . . . . 444.4.2. Conjunto B - Gcc, Libquantum . . . . . . . . . . . . . . . 444.4.3. Conjunto C - Gcc, H.264 . . . . . . . . . . . . . . . . . . 44

4.5. Resultados de las simulaciones . . . . . . . . . . . . . . . . . . . 444.5.1. Tasa de desaciertos en memoria cache compartida . . . . 454.5.2. Instrucciones por ciclos (IPC ) . . . . . . . . . . . . . . . 494.5.3. Ancho de banda utilizado . . . . . . . . . . . . . . . . . . 52

4.6. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5. Conclusiones 555.1. Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

A. Pintool de Instrumentacion 58A.1. Detalles de implementacion . . . . . . . . . . . . . . . . . . . . . 58A.2. Modo de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

B. Modulo Recolector de trazas 60B.1. Detalles de implementacion . . . . . . . . . . . . . . . . . . . . . 60B.2. Modo de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60B.3. Descompresor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

B.3.1. Modo de uso . . . . . . . . . . . . . . . . . . . . . . . . . 60

C. Simulador de jerarquıas de memoria cache 62C.1. Detalles de implementacion . . . . . . . . . . . . . . . . . . . . . 62C.2. Modo de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

D. Medio Digital 63D.1. Descompresor de Trazas . . . . . . . . . . . . . . . . . . . . . . . 63D.2. Documentacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63D.3. Compiladores gcc y g++ versiones 3.4.6 . . . . . . . . . . . . . . 63D.4. Generador de Trazas y Simulador

de Jerarquıas de Memoria Cache . . . . . . . . . . . . . . . . . . 64D.5. Framework PIN version 2.7-31933 . . . . . . . . . . . . . . . . . 64

Referencias 66

ii

Indice de figuras

1. Diagrama de un procesador doble nucleo con memoria cache denivel 2 de tipo compartido. . . . . . . . . . . . . . . . . . . . . . 1

2. Descomposicion de una direccion de memoria. . . . . . . . . . . . 43. Diagrama en bloques de la arquitectura de PIN. . . . . . . . . . 114. Diagrama en bloques de la arquitectura de Valgrind. . . . . . . . 125. Diagrama de secuencias del ambiente de desarrollo. . . . . . . . . 146. Informacion enviada desde el Controlador al Modulo de Proce-

samiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157. Secuencia operativa de la Pintool desarrollada. . . . . . . . . . . 168. Secuencia operativa del Modulo Generador de Trazas. . . . . . . 189. Secuencia operativa del Modulo Simulador de Jerarquıas de Memo-

ria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2010. Diagrama de Pila LRU para la aplicacion de la metrica (9). . . . 3111. Secuencia de la heurıstica de administracion dinamica. . . . . . . 3312. Diagrama de componentes del Simulador de Jerarquıas de Memoria. 3613. Esquema de la arquitectura utilizada para la simulacion. . . . . . 4114. Tasa de desaciertos para el conjunto de prueba A. . . . . . . . . 4615. Distribucion dinamica de zocalos para el conjunto de prueba A. . 4616. Tasa de desaciertos global para el conjunto de prueba A. . . . . . 4717. Tasa de desaciertos para el conjunto de prueba B. . . . . . . . . 4818. Tasa de desaciertos global para el conjunto de prueba B. . . . . . 4819. Distribucion dinamica de zocalos para el conjunto de prueba B. . 4920. IPC para el conjunto de prueba A. . . . . . . . . . . . . . . . . . 5021. IPC global para el conjunto de prueba A. . . . . . . . . . . . . . 5022. IPC para el conjunto de prueba B. . . . . . . . . . . . . . . . . . 5123. IPC global para el conjunto de prueba B. . . . . . . . . . . . . . 5124. Ancho de banda global para el conjunto de prueba A. . . . . . . 5225. Ancho de banda global para el conjunto de prueba B. . . . . . . 52

Indice de Tablas

1. Ejemplos de jerarquıas de memoria de procesadores. . . . . . . . 5

iii

1 INTRODUCCION

Capıtulo 1

1. Introduccion

1.1. Motivaciones de la Tesis

Los desarrollos de las arquitecturas multi-nucleo o Chip Multi-Processors(CMP) marcaron una mejora notable en el desempeno de las aplicaciones, yaque proporcionan una manera eficiente de ejecutar multiples de ellas, o a unamisma (a traves de diferentes subtareas) en forma simultanea. Esta mejora enla eficiencia de la ejecucion, se logra al contar con multiples unidades de proce-samiento individuales que tienen disponibles recursos de memoria privados ycompartidos.

Desde las primeras generaciones de procesadores, la latencia en los accesosa la memoria principal es la causa del bajo desempeno en la ejecucion de lasaplicaciones, ya que esta no responde a los pedidos de instrucciones y datos a lavelocidad que le es necesaria al procesador. Este factor se vuelve crıtico en losCMP actuales ya que se incrementa aun mas esta diferencia de velocidad al tenermultiples nucleos de procesamiento realizando accesos en forma simultanea [1].

Los procesadores cuentan con una memoria interna llamada cache (oculta),que funciona como apareador de velocidades entre el procesador y la memoriaprincipal [2]. En la actualidad, algunas arquitecturas de procesadores cuentancon multiples niveles de memoria cache. Por simplicidad y desempeno, algunosniveles se mantienen como privados para cada nucleo de un procesador, mientrasque otras arquitecturas exploran compartir el ultimo nivel de memoria cache en-tre diferentes nucleos del mismo procesador [3, 4].

En la figura 1 se muestra un diagrama de un procesador doble nucleo, condos niveles de memoria cache. El primero de ellos (L1) privado para cada nucleoy el segundo de tipo compartido.

CPU CPU

Caché L2

Caché L1 Caché L1

Procesador

Núcleo 0 Núcleo 1

Bus del Sistema

Memoria Principal

Figura 1: Diagrama de un procesador doble nucleo con memoria cache de nivel2 de tipo compartido.

1

1.2 Estado del arte 1 INTRODUCCION

Ademas de la clasificacion por niveles, las memorias cache de un procesadorse dividen en memorias cache de instrucciones y de datos. Las primeras, al alojarlas instrucciones de las aplicaciones ejecutadas tienen un comportamiento masordenado y predecible respecto de las segundas. Esta caracterıstica da como re-sultado que las memorias cache de datos tengan un menor rendimiento respectode las de instrucciones. Sumada a la caracterıstica anterior, la memoria cache dedatos es un recurso muy escaso comparada con la cantidad disponible de memo-ria principal. Finalmente, en las arquitecturas que implementan el ultimo nivelde memoria cache como compartido, se busca maximizar el uso los de recursosevitando la duplicidad de la informacion, con una baja latencia y reduciendo lacoherencia en el trafico de los datos.

Las memorias cache compartidas aportan grandes beneficios al desempeno,ya a que en el caso extremo de un solo nucleo en ejecucion con los demas sinactividad, el proceso ejecutandose, dispondrıa de toda la memoria cache com-partida que es de mayor tamano que las usadas como privadas para cada nucleo.Aunque, debido a este mayor tamano, posee una mayor latencia la cual es propa-gada a los niveles superiores de la jerarquıa. Por otro lado, la polıtica de reem-plazo LRU comunmente utilizada en las memorias cache, no distingue entre losdiferentes procesos y su distinta localidad de datos a lo largo de su ejecucion,lo cual aumenta la congestion al aumentar la cantidad de procesos en ejecucionsimultanea. La ausencia de aislamiento y administracion en el uso del espacioen memoria cache resulta en una degradacion del desempeno de los procesos enejecucion. Estos son los motivos principales que hacen del analisis del compor-tamiento en el modo de uso de la memoria cache de tipo compartida por partede las aplicaciones, sea de una remarcada importancia para lograr mejoras enel rendimiento en ambientes de multiples procesos en ejecucion simultanea.

En este sentido, se trabajo en el desarrollo de una herramienta capaz de cap-turar las referencias a memoria de multiples procesos en ejecucion simultanea,como tambien la simulacion de jerarquıas de memoria cache alimentadas pordichas referencias al vuelo (esto es, a medida que los procesos son ejecutados).El simulador construido, permite evaluar el desempeno de las aplicaciones al uti-lizar distintas polıticas de administracion para el espacio otorgado en memoriacache de tipo compartida.

1.2. Estado del arte

1.2.1. Memorias cache Privadas y Compartidas

A lo largo de los anos, la diferencia de velocidad entre el procesador y lamemoria principal a sido un incremento exponencial [5]. Para minimizar estadiferencia, los procesadores actuales cuentan con memorias de rapido accesollamadas memorias cache. Estas aprovechan el principio de localidad de las refe-rencias a memoria que se presenta en la mayorıa de las aplicaciones. El principiode localidad tiene dos vertientes. Se postula que, en la localidad espacial, elprocesador utilizara referencias a memoria cercanas respecto de la que esta refe-renciando en ese instante, mientras que en el principio de localidad temporal seenuncia que una referencia a memoria sera vuelta a referenciar en el corto plazo.De esta manera, resulta logico mantener una copia de los datos en una memoriade tamano reducido y de rapido acceso. Estas memorias son las llamadas cache.

Cuando una instruccion o dato no es encontrada en la memoria cache, se debe

2


recurrir al siguiente nivel en la jerarquıa de memoria. Esta situacion es conocidacomo un desacierto (miss) y siempre se busca minimizar su numero ya queimplica acceder a una memoria mas grande y por lo tanto mas lenta. Ademas,dado que cada nivel esta incluido en el anterior, este debera ser actualizado encaso de desacierto.

Otra caracterıstica que se busca para mejorar el rendimiento de los proce-sadores, es la de lograr la maxima capacidad de transferencia de informacion conla memoria principal. Esto se logra cuando se accede a conjuntos de datos rela-tivamente grandes ubicados en forma consecutiva. El inconveniente para lograreste objetivo es que el procesador usualmente consume los datos en un ordendistinto al que estan estos alojados. De esta manera se da una de las caracte-rısticas principales de las memorias cache que es la de transferir datos con lamemoria principal en bloques (tambien llamados lıneas) de un tamano especıfi-co y del lado del procesador, se efectuen las transferencias de instrucciones ydatos como ıtems individuales [6].

Dentro de los parametros principales de una organizacion de memoria cache seencuentran:

Tamano: El tamano de una memoria cache depende de su ubicacion dentrode la jerarquıa de memoria del procesador. Los procesadores actuales cuentancon multiples niveles de memoria cache siendo el mas cercano al procesador(Nivel 1) una memoria cache de muy poco tamano, como algunas decenas deKilobytes, pero de una velocidad tal que no produce demora al procesador. Amedida que se incrementa el nivel (Niveles 2, 3, etc), tambien se incrementa eltamano, con el consecuente incremento en el tiempo de acceso.

Tamano de Bloque: El tamano de bloque es la cantidad de bytes que sontransferidos entre dos niveles de memoria cache o a memoria principal.

Polıtica de reemplazo: Cuando se produce un desacierto, uno de los bloquesde la memoria cache debe ser reemplazado por el nuevo bloque a ingresar quecontiene la referencia requerida por el procesador. Este bloque a reemplazardebe ser elegido segun una polıtica adoptada al disenar la cache. Las siguientesson las polıticas mas usuales:

Aleatoria: Se elige un bloque en forma aleatoria para ser reemplazado.

FIFO: Se usa un algoritmo First In First Out (FIFO) para determinarque bloque sera el reemplazado.

Menos recientemente usado (LRU): Se reemplaza el bloque que hace mastiempo que no se ha referenciado en la cache.

Polıtica de ubicacion:

Correspondencia Directa: Cuando un nuevo dato solo puede ser ubicadoen un unico bloque en la cache.

Asociativa por conjuntos: Cuando el nuevo dato puede ser ubicado en unconjunto de bloques posibles.

3


Totalmente Asociativa: Cuando el nuevo dato puede ser ubicado en cualquierlugar.

Busqueda: Determinada por la polıtica de ubicacion, el acceso a la infor-macion alojada en una memoria cache es mediante indexacion. La direccion dememoria de un dato buscado puede descomponerse segun se muestra en la figura2:

Dirección del Bloque

Rótulo (TAG) Índice (Index) Desplazamiento (OFFSET)

Figura 2: Descomposicion de una direccion de memoria.

La forma de acceso es la siguiente: Primero se toman los bits que conformanel ındice o index, este permite acceder a un conjunto en particular dentro de lacache. Luego con los bits que conforman el rotulo o tag se verifica si el conjuntoindizado contiene el bloque buscado y finalmente con los bits que restan, queson los que forman el desplazamiento u offset, se selecciona dentro del bloqueelegido al ıtem solicitado.

Polıtica de Escritura: Cuando se escribe un ıtem en un bloque de una memo-ria cache, este debe tambien ser escrito en los siguientes niveles de la jerarquıapara conservar la consistencia de los datos. Existen dos polıticas para realizaresta accion:

Write-through: Cada vez que se escribe (actualiza) un bloque en memoriacache, se actualiza tambien el siguiente nivel de la jerarquıa.

Write-back: Solo se actualiza el siguiente nivel en la jerarquıa si se produceun desacierto al escribir un bloque.

La polıtica Write-back es la mas utilizada en las memorias cache actualespor ser la que mejor desempeno logra, ya que si el bloque a escribir se encuentraen la memoria cache (produciendo un acierto de escritura),se evitara el acceso alsiguiente nivel de la jerarquıa. Cuando se debe actualizar un bloque y este no seencuentra (desacierto de escritura), tambien se debe actualizar en el siguientenivel de la jerarquıa el bloque desalojado, conservando la consistencia de lainformacion pero insumiendo un doble acceso, el del nuevo bloque traıdo parala escritura y el desalojado.

Ubicacion en la jerarquıa: En los procesadores de multiples nucleos losniveles superiores de la jerarquıa son accedidos en forma exclusiva (privada) porcada nucleo, mientras que el nivel inferior es accedido por todos. Un esquemade esto se puede ver en la figura 1.

1.2.2. Clasificacion de desaciertos

La clasificacion de los desaciertos de una aplicacion en una memoria cache da-da es de gran utilidad para conocer su rendimiento. En [7], se da la siguienteclasificacion de los desaciertos:

4


Obligatorio (Compulsory): Es la tasa desaciertos de una cache de tamanoinfinito. Son los desaciertos debidos al acceso por vez primera a bloquesde memoria.

Capacidad (Capacity): Es la tasa de desaciertos de una cache con polıticade reemplazo LRU totalmente asociativa de igual tamano a la memoriacache bajo estudio, menos la tasa de desaciertos obligatorios. Estos de-saciertos son los causados al referenciar mayor cantidad de bloques quelos que caben en la memoria cache estudiada.

Conflicto (Conflict): Es la tasa de desaciertos de una cache bajo estudiomenos los desaciertos de capacidad y obligatorios.

Esta clasificacion conocida como 3C, es ampliamente utilizada para disenarnuevas organizaciones de memoria cache mas efectivas. En el trabajo desarro-llado en esta tesis, se adopto una clasificacion mejorada llamada Deterministic3C (D3C) o Clasificacion 3C Determinıstica propuesta en [8]. En el Capıtulo 3se describe en detalle los motivos de su adopcion en este trabajo.

1.2.3. Jerarquıas de memorias

La jerarquıa de memoria utilizada en un CMP a evolucionado en la disposi-cion de distintos niveles de cache, cada uno con mayor capacidad que el nivelanterior, logrando compensar la diferencia de velocidad de un nivel al siguientecon mayor capacidad de memoria. En el cuadro 1, se muestran ejemplos de je-rarquıas de memoria de distintos procesadores [9–11]. La primera columna in-dica el modelo de procesador, seguida por la cantidad de nucleos, y en las trescolumnas finales, la especificacion de los niveles de memoria cache. La descrip-cion de cada nivel indica el tamano de la cache, la asociatividad y el tamanode bloque. Los valores P o C en las columnas L2 o L3 indican si ese nivel esPrivado o Compartido para todos los nucleos (L1 es siempre privado).

Modelo # N. L1 L2 L3

Pentium D 2 32Kb-8-64B 2MB-8-64B P. -Core 2 Duo 2 32Kb-8-64B 4MB-16-64B C. -

i7 4 32Kb-4-64B 256Kb-8-64B P. 8Mb-16-64B C.Athlon II X3 3 64Kb-2-64B 1.5Mb-16-64B C. -

UltraSPARC IV+ 2 64Kb-4-32B 2MB-4-64B C. 32MB-4-64B C.

Cuadro 1: Ejemplos de jerarquıas de memoria de procesadores.

En la actualidad, luego de haber sido exploradas y evaluadas distintas op-ciones [10], las arquitecturas de memoria comparten el ultimo nivel de memoriacache ya que se logra un mayor rendimiento en la ejecucion de las aplicaciones.Esto es debido a que en el caso extremo de un solo nucleo en ejecucion conlos demas sin actividad (idle), el proceso ejecutandose dispondrıa de toda lamemoria cache que es de mayor tamano que las usadas como privadas paracada nucleo (esto es aplicado en la tecnologıa Smart Cache [12] y similares).Ademas, proveen un alto desempeno cuando los nucleos comparten informacion

5


entre si. Un conjunto de bloques de memoria cache puede ser accedido por to-dos los nucleos, evitando la copia innecesaria de informacion disminuyendo lalatencia.

Las memorias cache compartidas aportan grandes beneficios, pero tambienrepresentan un gran desafıo en cuanto a su administracion ya que como multi-ples procesos acceden a ella en forma simultanea se dan situaciones que en lascaches privadas no ocurren, como ser que un proceso sobre-escriba la informa-cion de otro proceso (ocasionando desaciertos de tipo inter-procesos) o algo quedeteriora aun mas el desempeno, que son los cambios en la localidad de datosque poseen los distintos programas que son ejecutados en un mismo instante[13]. Por esta razon se busca otorgar a cada proceso en ejecucion una cantidadde memoria cache con la cual logre el mejor desempeno posible sin que estoincurra en una baja del rendimiento de los demas procesos que tambien estanen ejecucion.

Asimismo, en la actualidad las memorias cache ocupan mas del 60 % de lasuperficie del procesador, y cada vez que se aumentan los parametros de esta,tales como su tamano y asociatividad se incurre en aumentar aun mas la super-ficie ocupada. Por estos motivos, surge la necesidad de realizar un analisis de loscomportamientos del uso del espacio asignado a cada proceso en una cache detipo compartida, dando ası un orden en la administracion del espacio disponible,mejorando sustancialmente el rendimiento general de todos los procesos.

1.2.4. Administracion de memorias cache compartidas

El estudio del comportamiento del ultimo nivel de la jerarquıa de memoriaes de gran interes ya que es donde los procesos que estan en ejecucion en cadauno de los nucleos del procesador comparten informacion, y desde cual se accedea la memoria principal del sistema. Esto hace que se produzcan interferenciasentre los procesos ya que los que acceden mas a la memoria principal general-mente ocuparan mas espacio en la memoria cache compartida en decrimentodel espacio ocupado por el resto de los procesos. Este tipo de interferencia esllamada desaciertos inter-procesos. Ademas, durante su ejecucion, los procesosmodifican su conjunto de trabajo (working set), repercutiendo en un mayor omenor espacio ocupado, lo cual indica la necesidad de adoptar una polıtica so-bre la administracion del espacio que cada proceso puede utilizar en la memoriacache compartida.

Las polıticas de administracion se pueden clasificar en:

Sin administracion: Una memoria cache de tipo compartida sin adminis-tracion sera mas simple de desarrollar en hardware, ocupara menos espacio portener solo la logica de una memoria cache comun, con la salvedad, de que debecontar con distintas interfaces para que todos los nucleos del procesador puedanaccederla en forma simultanea. Los procesos que hagan uso de sus recursos com-petiran por estos provocando una gran cantidad de interfencia de datos con elconsecuente decremento del rendimiento en su ejecucion. Un procesador quehace uso de esta polıtica es el IBM Power4 [14].

Administracion estatica: Con la administracion estatica se busca asignaruna cierta cantidad de espacio en la memoria cache a cada proceso en el mo-mento previo a su ejecucion, para ası evitar la interferencia entre ellos en el

6


uso de la memoria cache. Esto se puede realizar modificando en forma leve elcomportamiento de la TLB (Translation Lookaside Buffer) para que otorgue unespacio reducido de direcciones a cada proceso.

Si bien esta polıtica de administracion logra una mejora en el rendimientoen casos especıficos utilizados para estudio, no tiene en cuenta los cambios en eltamano del conjunto de trabajo que tiene cada proceso a lo largo de su ejecucion,resultando en un pobre rendimiento en las aplicaciones de uso normal, lo cualhace que esta polıtica sea descartada en la practica.

Administracion dinamica: Con esta polıtica se busca poder otorgar unacierta cantidad de espacio de memoria cache a cada proceso en ejecucion segunsu necesidad en forma dinamica, esto es, mientras este en ejecucion.

Pueden optarse por distintos objetivos con el espacio a asignar a cada pro-ceso. Buscar que todos los procesos tengan una cantidad apropiada de espaciopara que todos tengan un rendimiento similar, es una polıtica conocida comoequidad o fairness. Si en cambio se marca a un proceso como destacado paraotorgarle un mayor espacio respecto de los demas, se lo conoce como Utilitaristao Utilitarian[15].

Aquı, hay que tener en cuenta que se necesita adicionar nuevo hardware a lamemoria cache a fin de poder medir el uso que tiene cada proceso de esta, paraası tomar una decision cada vez que se desee realizar modificaciones al espaciootorgado a cada proceso.

1.2.5. Metodologıas utilizadas para el analisis

Para realizar el analisis del modo de uso del espacio en una memoria cache porparte de las aplicaciones existen distintas metodologıas y herramientas disponibles.Una de ellas es analizar su comportamiento sobre un simulador completo, lla-mada Execution Driven Simulation. Un ejemplo de una herramienta de este tipoes SimpleScalar [16]. Utilizado ampliamente por la comunidad cientıfica, es unsistema capaz de simular en detalle cualquier elemento de hardware de una ar-quitectura. Su principal desventaja consiste en que los resultados logrados seransiempre en base a hardware simulado y no real.

Otra metodologıa es la simulacion por trazas o Trace Driven Simulation demultiples procesos y/o hilos. Estas simulaciones tienen la ventaja de proveergran cantidad de informacion, son de relativamente facil implementacion y muyflexibles, pero cuentan con la desventaja de mostrar solo una instancia de ejecu-cion de las infinitas posibles, ya que la mayorıa de las herramientas desarrolladasvuelcan la informacion de las instrucciones y accesos de memoria obtenidos aun archivo de texto plano o en un formato comprimido. Esto anade otra desven-taja, ya que para realizar cualquier tipo de analisis sobre las trazas obtenidas,primero se debe contar con el espacio sufiente para alojar los archivos compri-midos, descomprimirlos y luego realizar su procesamiento, lo que insume tiempoy recursos nada despreciables.

En la actualidad para capturar la informacion necesaria de las aplicaciones seutiliza una tecnica llamada instrumentacion. Consiste en insertar nuevo codigoen un archivo fuente o un binario ejecutable para obtener la informacion almismo tiempo que es ejecutado sobre el hardware real. De esta manera se obtienela informacion de las aplicaciones sin necesidad de simular completamente cadaelemento de hardware, a la vez que se puede procesar la informacion evitando

7


el uso de archivos de almacenamiento. Ejemplos de aplicaciones desarrolladasactualmente que hacen uso de esta tecnica son CMP$im [17] y un simuladorque se beneficia de la aceleracion del procesamiento dado por los procesadoresgraficos [18].

1.2.6. Instrumentacion de binarios ejecutables

La instrumentacion de un proceso puede ser realizada en varias etapas: enel codigo fuente, en tiempo de compilacion, en la etapa de post link o en tiempode ejecucion. En la instrumentacion estatica, se inserta el nuevo codigo deinstrumentacion en los archivos fuentes de un programa o en el archivo eje-cutable. En cambio, en la instrumentacion dinamica o Dynamic Binary Instru-mentation (DBI), se inserta este nuevo codigo de instrumentacion en el binarioejecutable a medida que este se va ejecutando.

Dentro de la instrumentacion dinamica existen multiples herramientas lla-madas Dynamic Binary Analysis (DBA). Estas herramientas son muy utilespara obtener informacion sobre la ejecucion de binarios ya que no se necesitaninguna preparacion previa (como ser una recompilacion o linkeo). Los ejemplosmas nombrados de este tipo de herramientas son PIN y Valgrind [19].

Si bien PIN y Valgrind son herramientas muy utilizadas por la comunidadcientıfica, se opto por utilizar PIN ya que Valgrind no posee capacidad de ins-trumentar multiples procesos en forma simultanea ya que utiliza un metodo deserializacion de instrucciones que otras herramientas como PIN no utilizan.

1.2.7. Herramientas desarrolladas

Con el fin de estudiar el uso del espacio de la memoria cache de tipo compar-tida por distintos procesos en ejecucion, se desarrollo una herramienta capaz deprocesar la informacion obtenida al instrumentarlos con PIN. El diseno logra-do, utiliza modulos de procesamiento integrados a un Controlador de Procesos,que es el que se comunica con PIN para realizar la captura de la informacion.Para realizar las pruebas y validaciones requeridas a lo largo de este trabajo sedesarrollaron dos modulos:

Modulo Generador de Trazas: Fue desarrollado con el proposito de veri-ficar los datos (accesos a memoria de datos en instrucciones) por parte de losprocesos involucrados, teniendo en cuenta la ejecucion en forma simultanea deestos.

Modulo Simulador de Jerarquıas de Memoria Cache: Se tuvo comoobjetivo simular los parametros basicos de una memoria cache detallados en1.2.1, ası como las caracterısticas de hardware que afectan al desempeno de losprocesos, como ser latencias, tiempo de acceso, memorias de tipo bloqueante,ejecucion de multiples instrucciones por ciclo de reloj, etc. En el Capıtulo 4 sedescribe en forma detallada este modulo.

8

1.3 Objetivos de la tesis 1 INTRODUCCION

1.3. Objetivos de la tesis

Como corolario, el objetivo de la presente tesis consiste en el estudio del usodel espacio de la memoria cache de tipo compartida por parte de diferentes pro-cesos en ejecucion simultanea. Se propone una forma de administracion dinamicadel espacio de la memoria cache compartida que tiene por objetivo lograr un de-sempeno similar de todos los procesos en ejecucion administrando el espacio queestos pueden utilizar en la memoria cache segun la cantidad y tipo de desaciertosque se produzcan en este nivel de la jerarquıa utilizando la clasificacion D3C.Para ello se desarrollo una herramienta que permite tanto la captura de refe-rencias a memoria e instrucciones de distintos procesos en ejecucion simultanea,como tambien el procesamiento de estas referencias utilizando distintos modulostanto para generacion de trazas o simulacion de jerarquıas de memoria cache.

Con este ultimo modulo se obtuvieron los datos para las curvas y conclusionessobre la polıtica de administracion propuesta.

1.4. Organizacion de los capıtulos y secciones

En este capıtulo se presentaron las motivaciones y el estado del arte de lastecnologıas para la realizacion de esta tesis; junto con una introduccion a lasherramientas creadas para alcanzar su objetivo. En el capıtulo siguiente se ex-pondra el modo de funcionamiento y los motivos de la eleccion de los frameworksutilizados, ası como las validaciones y pruebas realizadas a las herramientas de-sarrolladas. El capıtulo 3 muestra el trabajo relacionado sobre la administracionde memorias cache compartidas y es donde se definen las metricas y la heurısticautilizada en la polıtica de administracion propuesta en esta tesis. En el capıtulo4 se describe en forma detallada el funcionamiento del simulador de jerarquıasde memoria y su configuracion al momento de realizar las simulaciones, ası co-mo los benchmarks elegidos para realizar la evaluacion del desempeno de laadministracion propuesta junto con los resultados obtenidos al ejecutarlos comoconjuntos de prueba, y finalmente, en el ultimo capıtulo se detallan las conclu-siones obtenidas y el trabajo futuro a realizar.

9

2 AMBIENTE DE DESARROLLO

Capıtulo 2

2. Ambiente de desarrollo

2.1. El framework PIN

La instrumentacion es la tecnica para insertar codigo extra en una aplicaciona fin de observar su comportamiento. Esto puede ser realizado en varias etapas,como ser: en el codigo fuente, en tiempo de compilacion, en la etapa de post linko en tiempo de ejecucion. PIN es una herramienta capaz de realizar instrumen-tacion de aplicaciones en tiempo de ejecucion en ambientes Linux (Con proce-sadores Intel® Xscale®, IA-32, Intel64 (64 bit x86) e Itanium®), Windows(arquitecturas IA-32 e Intel64) y MacOS (IA-32) [20]. Provee una API completa(Application Programming Interface) que sirve como una capa de abstraccionpara interactuar con las aplicaciones a instrumentar siendo posible escribir dis-tintas herramientas de instrumentacion llamadas Pintools. Se utiliza un compi-lador de tipo just-in time (JIT) para insertar y optimizar el codigo de instru-mentacion.

PIN compila la aplicacion a instrumentar directamente en el mismo ISA(Instruction Set Architecture) sin pasar por codigo intermedio, almacenandoeste nuevo codigo compilado para instrumentacion en un cache interno. Comosolo se ejecuta el codigo almacenado en este cache, se logra un gran desempenoen la ejecucion, superando al de Valgrind.

La arquitectura cuenta con una maquina virtual (Virtual Machine (VM))que consiste en el compilador JIT, un emulador que interpreta y emula ciertasinstrucciones que no puedan ser ejecutadas directamente (usualmente systemcalls que requieren un manejo especial) y un dispatcher que es el encargado de“despachar” las instrucciones provenientes de la aplicacion hacia el compiladorJIT.

Visto desde la perspectiva del usuario, la instrumentacion con PIN consisteen dos componentes principales:

Codigo de Instrumentacion.

Codigo de analisis.

Estos dos tipos de codigo residen en un mismo archivo, la Pintool. Amboscodigos son funciones en lenguage C++ de la API provista por PIN. Las fun-ciones de instrumentacion son las encargadas de inspeccionar el codigo generadopara decidir si es necesario (y donde) inyectar las llamadas a las funciones deanalisis. Las funciones de analisis son las que finalmente obtienen la informacionde la aplicacion [21].

10

2.1 El framework PIN 2 AMBIENTE DE DESARROLLO

En la figura 3 se muestra un diagrama en bloques de la arquitectura de PIN.

Pintool

API para Instrumentación

Compilador JIT

Unidad deEmulación

Dispatcher

CachéDe

Código

Máquina Virtual (VM)

Sistema Operativo

Hardware

PIN

Aplicación1

2

3

Figura 3: Diagrama en bloques de la arquitectura de PIN.

Capa 1: En esta capa reside la aplicacion y la Pintool. Es el nivel de usuario,donde se obtiene la informacion final por parte del framework PIN.

Capa 2: La Pintool utilizando sus funciones de analisis, es la encargada de in-dicarle a PIN que tipo de informacion obtener. Las funciones de instrumentacionindican cuando y donde en la ejecucion debe ser obtenida esta informacion. Elcompilador JIT toma el codigo de la aplicacion y le anade las instruccionesnecesarias (en el mismo ISA del hardware utilizado) para obtener la informa-cion segun el tipo de funcion de analisis se haya llamado en la Pintool. Este nuevobloque de codigo compilado es enviado al cache para su posterior ejecucion.

Capa 3: El hardware ejecuta las instrucciones que la VM le envıa. Finalmente,PIN envıa la informacion obtenida como resultado de las funciones de analisisa traves de la API a la Pintool.

11


2.1.1. Comportamiento en tiempo de ejecucion

PIN es capaz de instrumentar un binario ejecutable incluso si este crea nuevosprocesos hijos y/o nuevos hilos de procesamiento. Para cada proceso hijo creado,una copia de la Pintool que instrumenta al proceso padre instrumentara a estenuevo proceso creado, mientras que los nuevos hilos (threads) son controlados ysincronizados utilizando la API provista por PIN dentro de la Pintool.

Este comportamiento fue el que hizo que se adoptara el diseno detallado enla seccion 2.2.

2.1.2. Diferencias de PIN con el framework Valgrind

Valgrind esta construido en base a un diseno modular, con un nucleo llamadoCoregrind, que implementa un procesador x86 sintetico, e interactua con otrosmodulos (skins), para dar las distintas funcionalidades a traves de herramientas(las mas conocidas Memcheck y Cachegrind).

Los modulos interactuan de la siguiente manera; cuando se ejecuta un pro-grama de usuario sobre Valgrind, el modulo central toma el control del mismo,lee el bloque de codigo a ejecutar y lo pasa al modulo correspondiente. Estemodulo instrumenta el bloque de codigo recibido y se lo retorna a Coregrindpara que este lo ejecute. La manera de instrumentar un bloque de codigo de-pende de la herramienta utilizada (Memchek, Cachegrind, etc) [22]. Como sepuede apreciar el diseno es muy similar al que tiene PIN.

Ilustrada en la figura 4, se muestra la secuencia de la instrumentacion deaplicaciones realizada por Valgrind.

Aplicación

CoreGrind Skin

Hardware

1

2

34

Figura 4: Diagrama en bloques de la arquitectura de Valgrind.

1. Las instrucciones que componen a la aplicacion son leıdas e interpretadaspor el modulo CoreGrind dentro de la VM de Valgrind.

2. CoreGrind envıa las instrucciones al skin de valgrind para que este le adi-cione las instrucciones necesarias para instrumentar segun la programacionrealizada por el usuario.

3. El codigo de la aplicacion ya instrumentado es envıado nuevamente a Core-Grind.

12


4. CoreGrind despacha el codigo instrumentado al hardware para que estelo ejecute.

La diferencia mas relevante para la aplicacion en nuestros estudios, se da enel funcionamiento de los mecanismos de bloqueo (lock) que implementa cadaherramienta al instrumentar una aplicacion de multiples hilos o procesos.

Valgrind serializa (es decir ejecuta uno por vez) cada hilo utilizando meca-nismos de bloqueos. Solo el hilo que posee la llave de acceso del mecanismo debloqueo puede ejecutarse mientras que los demas hilos esperan a que el hilo enejecucion termine, y libere la llave o pasen 100.000 bloques de codigo (este valores un parametro que puede ser modificado). El segundo mecanismo de bloqueoes implentado usando un pipe que contiene un caracter; cada hilo trata de leerdicho pipe, logrando que solo un hilo lo lea por vez. Cuando este hilo terminasu ejecucion, inserta nuevamente el caracter en el pipe para que otro hilo loobtenga. Finalmente un mecanismo en el nucleo de Valgrind es el encargado deadministrar la ejecucion de cada hilo ası como su ordenamiento en la ejecucionevitando ası que multiples hilos se ejecuten cada vez.

Valgrind implementa un tercer mecanismo de serializacion, el cual utilizauna version serializada de las bibliotecas del sistema operativo Unix libpthread.Esto provoca que solo sea posible instrumentar programas que utilicen estabiblioteca, que ademas tiene problemas aun no solucionados para replicar sucomportamiento dentro del nucleo de Valgrind [23].

PIN inicia una aplicacion asumiendo que no es multi-hilo. Crea a tal fin unarea donde guardara la informacion pertinente del hilo (como ser valores delos registros del procesador). Si luego PIN descubre que la aplicacion lanza unnuevo hilo, limpia su cache, recompila el codigo asumiendo que es multi-hilo,creando areas de datos especıficas para hilo y continua la ejecucion. Esto evitael uso de una biblioteca especıfica como Valgrind.

Para soportar el uso de multiples procesos, PIN lanza nuevas copias de simismo y la Pintool que instrumenta al proceso “padre”. Como una Pintoolcorre como un plugin dentro de PIN, esta corre dentro del mismo espacio dedirecciones virtuales que PIN, ası como el binario ejecutable que es instrumen-tado, dando a la Pintool el acceso a toda la informacion necesaria del binarioinstrumentado.

Al realizar la instrumentacion, PIN se encarga de restaurar todos los registrosde tipo entero del procesador, pero no los de tipo punto flotante. Para estosultimos el usuario es el encargado de restaurar sus valores luego de una llamadaa cada rutina de instrumentacion.

Por los motivos antes detallados, como ser mayor desempeno, posibilidadde instrumentar multiples hilos y procesos en forma simultanea sin alterar la“simultaneidad” real de estos al ser ejecutados, es que se eligio PIN para realizarla instrumentacion dinamica y no Valgrind.

Para el desarrollo de esta tesis, se utilizo un conjunto de benchmarks de tipoentero de la SPEC CPU2006 [24], ya que con estos se pueden lograr los objetivosde analisis propuestos sin complejizar el desarrollo de la Pintool.

13

2.2 Ambiente de desarrollo creado 2 AMBIENTE DE DESARROLLO

2.2. Ambiente de desarrollo creado

Teniendo en mente el comportamiento de los distintos programas a serinstrumentados y el objetivo principal de esta tesis, se opto por el diseno que sepropone a continuacion.

Este consiste en una Pintool, un Controlador de Procesos y dos contenedoresde mensajes mediante las cuales el Controlador de Procesos y la Pintool secomunican. El Controlador es responsable por la administracion en la ejecucionde cada proceso instrumentado por la Pintool, indicando cuando puede seguirsu ejecucion; previo registro del proceso.

En el siguiente diagrama de secuencias, se muestra el funcionamiento delambiente de desarrollo creado.

Proceso

Pintool

Controlador

Contenedor de RegistroContenedor de Información

Módulo de Aplicación

1

2

3

4

5

Figura 5: Diagrama de secuencias del ambiente de desarrollo.

1. La Pintool detecta el comienzo del proceso e ingresa en el contenedor deregistro el PID (Process Identifier) del nuevo proceso a instrumentar.

2. El Controlador lee el PID del nuevo proceso a controlar y lo almacenapara ası anadirlo en la secuencia iterativa de ejecucion de procesos.

3. Cada Pintool envıa los datos obtenidos de la instrumentacion a su con-tenedor exclusivo de informacion con el Controlador.

4. De forma iterativa el Controlador toma los datos del contenedor de infor-macion de cada proceso registrado y la envıa al modulo de procesamiento.

14


5. Al finalizar el envıo de la informacion al modulo de procesamiento se vuelveal paso anterior.

La informacion que se envıa al modulo de procesamiento desde el Controladorde Procesos, tiene el siguiente formato:

Identificador de

Proceso

Dirección de

Instrucción

Tipo de

Acceso

Direcciónde

Acceso

Tamañode

Acceso

Figura 6: Informacion enviada desde el Controlador al Modulo de Procesamien-to.

Con este diseno de Controlador - AutoRegistro el ambiente es capaz deanalizar cada instruccion y referencia a memoria de datos de multiples procesosen ejecucion simultanea, evitando los problemas asociados a la concurrencia deestos. Tambien se aisla la captura de informacion del analisis que se les rea-liza, dando la posibilidad de procesar la informacion en modulos independientesvinculados al Controlador de Procesos.

2.2.1. Pintool de Instrumentacion y Controlador de Procesos

El funcionamiento de la Pintool para obtener las instrucciones ejecutadas ylas referencias a memoria de un proceso esta basada en la herramienta Pina-trace provista como ejemplo por el framework PIN para capturar referencias amemoria.

Para obtener dichas referencias se utiliza una funcion de instrumentacion quees llamada cada vez que se ejecuta una instruccion. Esta detecta si la instruccionaccede a memoria de datos o no y actua en consecuencia llamando a una funcionde analisis especıfica. Si la instruccion no accede a memoria de datos, la funcionde analisis solo envıa el identificador de proceso y la direccion de la instruccion.En cambio si la instruccion accede a memoria de datos, obtiene la cantidad deaccesos que realiza, y para cada uno de ellos, detecta si es un acceso de lecturao escritura y llama a la funcion de analisis que le corresponde a cada tipo deacceso. Esta ultima es la encargada de enviar la informacion a su contenedor.

A continuacion, se indican la secuencia de pasos para realizar la instru-mentacion junto con un diagrama de secuencias ilustrado en la figura 7:

1. Se inicia la aplicacion. Se obtiene el Process Id (PID) del proceso a ins-trumentar y se crean los contenedores de mensajes necesarios para la co-municacion con el Controlador de Procesos.

2. Se registra el proceso en el Controlador y se prosigue con la ejecucion dela aplicacion.

3. Cada vez que se ejecuta una instruccion, PIN llama a la funcion de ins-trumentacion. Esta obtiene la informacion de la instruccion, detecta susparametros y llama a la funcion de analisis correspondiente.

4. La funcion de analisis obtiene los parametros de la instruccion. Segun eltipo de instruccion (no acceso a memoria de datos, acceso de lectura oacceso de escritura) se llama a una funcion de analisis en particular.

15


Inicio de Aplicación

Registro de Nuevo Proceso

Llamada a Función de Instrumentación

Acceso de LecturaAcceso de Escritura Sin acceso

Registro de Información

Finalización de Aplicación

1

2

3

4

5

6

Llamada a Función de Análisis

Figura 7: Secuencia operativa de la Pintool desarrollada.

16


5. La funcion de analisis escribe en el contenedor de informacion los datosde la instruccion analizada. Los pasos 4 y 5 se repiten en cada instruccionde la aplicacion.

6. Al detectar el fin de la ejecucion de la aplicacion se llama a una funcionde instrumentacion que es la encargada de finalizar los contenedores decomunicacion creados.

La comunicacion con el controlador se realiza a traves de dos tipos colas demensajes (los antes mencionados contenedores) del sistema operativo Unix 1.La primera de ellas es una cola de registro de procesos (el bloque marcado comoContenedor de Registro en la figura 5) de tipo no bloqueante.

Al iniciar la instrumentacion de un proceso, la Pintool ingresa un mensaje enesta cola y sigue su ejecucion. El mensaje es leıdo por el Controlador de Procesosy este lo ingresa en su secuencia iterativa de ejecucion. El mensaje consiste enel PID (Process Identifier) del proceso ası el Controlador puede almacenarlo ycoordinar su ejecucion.

El segundo tipo de cola de mensaje, es de tipo bloqueante (al ingresarle unmensaje, el proceso en ejecucion se queda bloqueado hasta que este mensajees leıdo. Es el bloque marcado como Contenedor de Informacion en la figu-ra 5). Este comportamiento sirve para que el Controlador de Procesos puedasincronizar la ejecucion de cada proceso instrumentado ya que un proceso con-tinuara su ejecucion solo si el Controlador de Procesos lee la informacion desu cola de mensajes. Cada Pintool crea una cola de mensajes de este tipo alcomenzar la instrumentacion de un proceso y se utiliza el PID del proceso ins-trumentado como llave de acceso.Como el Controlador de Procesos ya tiene almacenado el PID del proceso porqueeste se registro previamente, ya posee la llave para acceder a la informacion dela cola de mensajes.

Este diseno posibilita ejecutar instruccion por instruccion cada proceso ins-trumentado. Si bien esto hace que el desempeno en la obtencion de la infor-macion disminuya considerablemente, es algo necesario para poder realizar elanalisis del objetivo de esta tesis. Para analizar multiples procesos ejecutandoseen simultaneo, es necesario reproducir esta simultaneidad en su funcionamiento(i. e. multiples accesos concurrentes a memoria cache). Esto implica reproducirhardware especıfico para procesar informacion en paralelo lo mas exactamenteposible utilizando un simulador por software (el modulo Simulador de Jerarquıasde Memoria) en el que solo se puede ingresar la informacion de los procesos ana-lizados en forma serializada (obtenida a traves de la iteracion realizada por elControlador de Procesos).

Finalmente, una caracterıstica importante de este diseno, comentada ante-riormente, es que se desacopla la captura de informacion de su procesamiento.El Controlador de Procesos es el encargado de tomar la informacion provenientede la Pintool y ponerla a disposicion del respectivo modulo para ser tratada.Este modulo puede estar dentro del controlador (como una clase o funcion, talcual los desarrollados aquı) o ser una aplicacion independiente en comunicacioncon el Controlador de Procesos.

1Si bien se utilizaron colas de mensajes incluidas en Unix, se puede portar la herramientaa otros sistemas operativos sin alterar el diseno propuesto.

17


2.2.2. Modulo 1: Recoleccion de trazas

Este modulo se encarga de tomar las instrucciones y las referencias a memo-ria obtenidas por la Pintool, las almacena en un contenedor en memoria principalpara luego comprimirlas cuando se alcanza un lımite establecido. Este lımite,implementado como un parametro configurable, modifica la tasa de compre-sion del archivo que contiene las referencias a memoria. Si se aumenta su valorse lograran tasas de compresion mas altas pero ocupando mayor cantidad dememoria principal (el contenedor sera mas grande), en cambio si se disminuyeel valor, se bajara la tasa de compresion pero se ocupara menor cantidad dememoria principal. Los detalles de implementacion y el modo de uso de estemodulo se encuentran en el Apendice B.

En la figura 8 se muestra la secuencia operativa del generador de trazas:

Pintool + Controlador de Procesos

Contenedor de Compresión de Instrucciones

Compresor (Zlib)

Archivo de Instrucciones Comprimidas

Lógica del Generador De Trazas

Módulo Generador De Trazas

1

2

3

4

Figura 8: Secuencia operativa del Modulo Generador de Trazas.

18


1. El Controlador de Procesos le envıa la informacion de instrumentacion almodulo.

2. La logica del modulo ingresa la informacion de instrumentacion en el con-tenedor de compresion.

3. Si el contenedor se llena, se comprime la informacion utilizando para ellouna funcion de la biblioteca Zlib [25] y se la envıa al archivo final en disco.

La informacion almacenada en el archivo comprimido es la misma que provienedel Controlador de Procesos. Esta forma de almacenamiento fue la que seadopto a fines de analizar y verificar en forma simple las trazas obtenidas. Acontinuacion se muestra un fragmento del contenido del archivo comprimido:

Para cada instruccion, se almacena el PID del proceso instrumentado y ladireccion de la instruccion ejecutada. Ademas, para las instrucciones que accedena memoria de datos, se almacena el tipo de acceso W=Escritura, R=Lectura, ladireccion de memoria de datos accedida y tamano de dicho acceso.

...

18147 0xb788ea91

18152 0xb772b8ae R 0xbfa43238 4

18147 0xb788eaa4 W 0xbfb84748 4

18147 0xb788eaa7 R 0xb78a9ff4 4

18152 0xb7715a91

18147 0xb788ea9b

18152 0xb7715a9b

18147 0xb788eaa1

18152 0xb7715aa7 R 0xb7730ff4 4

...

DescompresorPara leer la informacion almacenada en los archivos comprimidos se desa-

rrollo una aplicacion capaz de descomprimir por secciones en forma iterativa oen forma total las trazas obtenidas. El motivo de su creacion fue el de visualizary estudiar la informacion proveniente de la instrumentacion de una forma masconveniente.

19


2.2.3. Modulo 2: Simulador de jerarquıas de memorias cache

En este modulo, el objetivo principal es simular distintas jerarquıas de memo-rias cache. En su desarrollo se tuvieron en cuenta las caracterısticas princi-pales del funcionamiento de un procesador, ası como la necesidad de simularla heurıstica propuesta de administracion dinamica de memorias cache compar-tidas. El siguiente diagrama de secuencias muestra su funcionamiento basico:

Pintool + Controlador de Procesos

Ingreso de instrucciones a ejecutar a núcleos de proceso

Módulo Simulador de Jerarquías de Memoria

1

Ejecución instrucciones

2

Cálculo tiempos de acceso

3

Archivo de Informaciónde ejecución

Registro de Información

4

5

6

Figura 9: Secuencia operativa del Modulo Simulador de Jerarquıas de Memoria.

1. El Controlador de Procesos le envıa la informacion de instrumentacion almodulo.

20

2.3 Validacion del entorno de desarrollo 2 AMBIENTE DE DESARROLLO

2. Se ingresan las instrucciones a ejecutar en cada nucleo del simulador. Alser un simulador superescalar, se ingresan multiples instrucciones para serejecutadas en forma simultanea.

3. Las instrucciones de cada nucleo son ejecutadas. Se accede a la jerarquıa dememoria simulada y se cuenta el tiempo de acceso, medido como cantidadde ciclos de ejecucion de cada una. En este punto se puede acceder a laheurıstica de administracion dinamica elegida.

4. Luego de cada ciclo de ejecucion se vuelve al punto 2, para ingresar lasnuevas instrucciones a ejecutar.

5. Si la cantidad de ciclos de ejecucion simulados llega al valor de una cons-tante predefinida, se obtiene la informacion de los accesos a la jerarquıade memoria ası como de los nucleos y se envıa a un archivo en formatoCSV (Comma Separated Values).

2.3. Validacion del entorno de desarrollo

Para la validacion de la informacion obtenida se utilizaron distintos meto-dos como: simulaciones de programas con valor teorico conocido de desaciertos,pruebas unitarias de modelo y de integracion. Fueron de gran utilidad a la ho-ra de encontrar errores, reformular hipotesis y en la validacion de los datosobtenidos para la elaboracion de las conclusiones alcanzadas.

2.3.1. Modelo del lazo simple

Se creo un programa en lenguage C++ que reproduce el comportamiento delModelo del lazo simple [26]. Este modelo consiste en referenciar iterativamenteuna zona contigua de memoria. Cada bloque es referenciado en el mismo byte,siendo el salto entre las referencias de exactamente un bloque de cache (exceptopara la ultima referencia que salta hacia atras en memoria a efectos de cerrar ellazo).

Su aporte para el uso en la comunidad cientıfica es que la cantidad de aciertosy desaciertos en cache son conocidas en forma teorica. Para lazos mas pequenosque la cache que lo contiene, la tasa de desaciertos es cero, independientementede la configuracion de esta. Cuando los lazos son mas grandes, comienzan aproducirse desaciertos. Por ejemplo, para una cache de B bloques, si el lazo esde un tamano entre B y 2B, las memorias cache asociativas por conjuntos conLRU funcionan peor a medida que la asociatividad aumenta. Por lo tanto unacache totalmente asociativa tiene la peor tasa de desaciertos y una asociativapor conjuntos funciona mejor [6].

Los parametros de entrada del programa desarrollado son el tamano del lazo,la cantidad de iteraciones a realizar y el tamano de bloque. Fue utilizado pararealizar las primeras pruebas para conocer como utilizar la framework PIN.Tambien se lo utilizo para verificar la instrumentacion realizada por la Pintooldel ambiente desarrollado, ası como la correcta comunicacion de esta con elControlador de Procesos.

21


2.3.2. Desarrollo de pruebas unitarias

Para la validacion del simulador de jerarquıas de memoria se utilizo el Frame-work CUTE C++ [27] para realizar pruebas unitarias.

Este Framework puede ser utilizado como un plugin dentro del IDE EclipseCDT [28] que fue el entorno de trabajo que se utilizo para el desarrollo. CUTEC++ permitio desarrollar las pruebas basicas necesarias de cada una de laspartes del simulador ası como las pruebas de integracion.

2.3.3. Pruebas unitarias

Las pruebas de modelo consisten en funciones que evaluan la funcionalidadpropia de cada componente de hardware simulado. Como ejemplo, las pruebasdesarrolladas para la clase encargada de simular la funcionalidad de la memoriacache fueron:

Accesar: Se evaluan distintas direcciones de memoria para determinar elcomportamiento del componente. Se espera que cada acceso se ubique enla vıa que le corresponda segun la polıtica de reemplazo utilizada, ası comoen el bloque que le corresponda.

Cache Bloqueada: Como se simula una memoria cache bloqueante, estevalor, que es un parametro del componente, se evalua ingresando distintasdirecciones de memoria y esperando que la memoria se bloquee (no aceptemas accesos) al alcanzar el valor del parametro configurado previamente.

Obtener tasa de desaciertos: Se ingresan distintas direcciones, segun unpatron conocido y se evalua la tasa de desaciertos obtenida con el va-lor calculado previamente. Aquı se utilizo el modelo de lazo simple pararealizar pruebas mas exaustivas.

Todas estas pruebas, son ejecutadas para distintas configuraciones de memo-ria. En el componente encargado de simular la memoria cache de tipo com-partida, ademas de ejecutar las mismas pruebas anteriores, se debe probar sufuncionalidad especıfica, con las siguientes pruebas:

Accesar dinamico un unico proceso: se evalua si la memoria cache realizaalgun tipo de modificacion en su comportamiento en ejecucion. Al ser ununico proceso, el resultado exitoso es que este cuente con todo el tamanodisponible, comprobandose al medir la tasa de desaciertos lograda.

Accesar dinamico con dos procesos sin informacion previa: se evalua elcomportamiento de la heurıstica propuesta para la administracion dinami-ca con dos procesos sin informacion previa sobre su ejecucion. El resultadoexistoso es la asignacion en forma igualitaria del espacio a cada uno.

Accesar dinamico con cuatro procesos: misma evaluacion anterior, pero eneste caso con 4 procesos en ejecucion.

Administrar el ingreso de un nuevo proceso contando con informacionprevia: Esta es la prueba mas crıtica ya que se ingresa un nuevo proceso yes de esperar que se le asigne el espacio necesario respetando la heurısticade administracion.

22


Ası como en el caso del componente que simula memorias cache, cada pruebase ejecuto con distintas configuraciones. Cada uno de los componentes desa-rrollados para el modulo simulador de jerarquıas de memoria cuenta con pruebasespecıficas de su funcionalidad.

El otro tipo de pruebas unitarias desarrolladas, son las llamadas de inte-gracion, que buscan probar el funcionamiento de multiples componentes entresı. Como varios de estos componentes del simulador estan construidos a su vezpor otros componentes, las pruebas se realizaron con la tecnica conocida comoBottom Up, que consiste en probar los componentes inferiores (individuales), yluego los superiores (los que estan construidos por otros componentes). Comoejemplo, las pruebas de integracion para evaluar el componente que simula unnucleo del procesador, que esta construido con componentes individuales co-mo: cache, instruccion, proceso, cache compartida y otros, evaluan el correctofuncionamiento del componente superior (en este caso el nucleo), aceptando yesperando el buen funcionamiento de los componentes inferiores. Otras prue-bas de integracion consistieron en tomar al modulo simulador como una “cajanegra”. Estas utilizan multiples modelos de lazo simple para ingresar referen-cias, donde el exito de la prueba consiste en corroborar la salida al final de laejecucion de estos. Se utilizaron para validar los valores teoricos de las tasasde desaciertos que se debıan obtener para memorias cache sin ningun tipo deadministracion, ası como para validar las primeras pruebas de desempeno de laheurıstica de administracion dinamica expuesta en el Capıtulo 3.

Para ejecutar todas las pruebas unitarias desarrolladas para el simulador dejerarquıas de memoria, se debe ingresar un parametro especıfico al ejecutarlo.Los detalles de implementacion y el modo de uso se encuentran en el ApendiceC.

23

3 ADMINISTRACION DINAMICA DEMEMORIAS CACHE COMPARTIDAS

Capıtulo 3

3. Administracion dinamica dememorias cache compartidas

3.1. Introduccion

En las arquitecturas multi-nucleo o chip multi-processors (CMP), el ultimonivel de memoria cache es tıpicamente compartido por los multiples nucleospara maximizar el uso los de recursos, evitando la duplicidad de la informacion yreduciendo el trafico al disminuir la coherencia. Ademas, permiten una alocaciondinamica de recursos mas flexible; en el caso extremo, un nucleo puede utilizartodo el espacio en cache, si los demas nucleos estan parados (estado idle).

Una memoria cache compartida tiene un mayor tamano en comparacion auna cache privada que se encuentre en el mismo nivel de la jerarquıa, que juntocon los beneficios antes mencionados permite reducir el numero de accesos amemoria principal. Pero, su mayor tamano implica una mayor latencia, la cuales propagada a los niveles superiores en la jerarquıa. Por otro lado, una memoriacache de tipo privada tiene menor latencia pero es ineficiente en uso de su espacioya que la jerarquıa contendra multiples copias de los datos compartidos entreprocesos.

La polıtica de reemplazo LRU comunmente utilizada en las memorias cache,no distingue entre los diferentes procesos y su distinta localidad de datos a lolargo de su ejecucion, lo cual aumenta la congestion al aumentar la cantidad deprocesos en ejecucion simultanea. La ausencia de aislamiento y administracionen el uso del espacio en memoria cache resulta en una degradacion del desempenode los procesos en ejecucion [29]. Por estos motivos se hace necesario proponerpolıticas de administracion de los recursos a fin de minimizar los efectos antesdescriptos.

En este capıtulo se propone una nueva polıtica de administracion dinamica,basada en una heurıstica que contempla la clasificacion de desaciertos de ca-da proceso en ejecucion, para ası, determinar que accion es conveniente tomarcon la cantidad de espacio en memoria cache compartida asignada a cada uno,mejorando la equidad de los recursos acaparados por cada proceso, teniendoesto como consecuencia, una mejora del rendimiento efectivo de todos ellos.

3.2. Trabajo Relacionado

Suh et al. [30–33], propone y desarrolla la administracion de memoriascache compartidas utilizando el concepto de Columnization o “Columnizacion”que consiste en administrar el espacio otorgado a cada proceso, variando laasociatividad, es decir activando o desactivando vıas de la memoria cache. Laheurıstica utilizada esta basada en el greedy algorithm o “algoritmo goloso”,el cual habilita nuevas vıas de la memoria cache a medida que estos requierenmas recursos. Los aspectos mas interesantes de esta propuesta son la simplezatecnica para aplicarla en hardware real y la mejora en la eficiencia del consumo

24

3.2 Trabajo Relacionado3 ADMINISTRACION DINAMICA DE

MEMORIAS CACHE COMPARTIDAS

energetico, ya que al poder activar o desactivar vıas segun necesidad, las vıasdesconectadas no tendran consumo de energıa.

Moreto et al. [34, 35], expone algunas debilidades de la polıtica de adminis-tracion antes propuesta. La mas importante de ellas es la utilizacion del algorit-mo goloso para administrar el espacio en memoria cache, ya que este funcionabien en ambientes crecientes en la necesidad de recursos, pero no en ambientesdonde la necesidad es variable. Ademas, destaca la obligacion de realizar unaclasificacion de los desaciertos ya que estos no afectan de igual manera al de-sempeno.

En el trabajo realizado por Kim et al. [36], se propone un cambio en elobjetivo de mejorar el rendimiento efectivo de cada proceso que accede a unamemoria cache compartida, por el de buscar una equidad en el rendimientode todos ellos. Para evaluar el desempeno logrado utilizando su propuesta deadministracion, propone cinco metricas que estan relacionadas directamente conel desempeno de la memoria cache compartida, insensibles a factores externos,como el nivel en la jerarquıa donde se encuentra o la latencia de la memoriaprincipal. Estas metricas, detalladas para un par de procesos i, j en ejecucionsimultanea, son descriptas a continuacion:

M ij1 = |Xi −Xj | , donde Xi =

Desaciertos compartidosiDesaciertos dedicadosi

(1)

M ij2 = |Xi −Xj | , donde Xi = Desaciertos compartidosi (2)

M ij3 = |Xi −Xj | , donde Xi =

Tasa de Desaciertos compartidosiTasa de Desaciertos dedicadosi

(3)

M ij4 = |Xi −Xj | , donde Xi = Tasa de Desaciertos compartidosi (4)

M ij5 = |Xi −Xj | , donde Xi = Tasa de Desaciertos compartidosi −

Tasa de Desaciertos dedicadosi (5)

Se utilizan como valores para el calculo, la tasa de desaciertos de un procesocuando este corre en forma independiente (llamados, desaciertos dedicados) yen simultaneo con otros (desaciertos de tipo compartido), y se busca minimizarel valor de M ij

x para mejorar la equidad. La metrica (1), trata de igualar laproporcion de los incrementos en los desaciertos de cada proceso, mientras que(2) trata de nivelar el numero de desaciertos. De manera similar, la metrica(3) trata de igualar la proporcion de los incrementos en los desaciertos de cadaproceso mientras que (4) trata de nivelar la tasa de desaciertos. Finalmente, (5)trata de equilibrar la tasa de desaciertos para cada proceso.

Las metricas (2) y (4) refuerzan la equidad en terminos absolutos, esto es, lacantidad de desaciertos o la tasa de desaciertos al ejecutar los procesos en unamemoria cache compartida junto a otros procesos. La desventaja de estas dosmetricas es que pueden sobre-penalizar a las aplicaciones con pocos desaciertoso una baja tasa de desaciertos.

En las metricas (1) y (3), la cantidad de desaciertos y la tasa de desaciertoses normalizada segun los valores obtenidos al ejecutar las aplicaciones juntocon otros procesos en ejecucion, por lo que el incremento en los desaciertos (ola tasa de desaciertos) es proporcional a aquellos obtenidos en el ambiente deejecucion compartida. La normalizacion tiene sentido, cuando las aplicaciones

25

3.2 Trabajo Relacionado3 ADMINISTRACION DINAMICA DE


sufren de una alta cantidad de desaciertos (o tasa de desaciertos), ya que muchosde esos desaciertos son de tipo inter-procesos, lo cual da una idea del nivel desolapamiento de los procesos en un ambiente de ejecucion simultanea.

La ultima metrica propuesta (5), realiza una resta de los valores de las tasasde desaciertos obtenidas en un ambiente con recursos compartidos respecto delde un ambiente con recursos dedicados.

Luego de analizar los resultados obtenidos al ejecutar su ambiente de eva-luacion, concluye que la metrica (1) es la que mejor equidad provee, no soloen promedio sino a traves de todos los benchmarks que utilizaron. Su corolarioqueda expuesto en la siguiente frase:

“...optimizar la equidad de rendimiento de cada proceso usualmente redundaen una mejora del rendimiento de todos los procesos en ejecucion simultanea,mientras que ir en busca del mejor rendimiento de cada uno no necesariamentees equitativo para todos. Esto es debido a que un mejor rendimiento en unproceso se logra a expensas de la equidad de recursos, favoreciendo a algunosprocesos que son mas facilmente mejorables sobre el resto.”

De esta manera, proporciona una manera simple y eficiente de comparar laequidad en el uso de los recursos para cada proceso, pero tiene el inconvenientede necesitar saber la tasa de desaciertos de un proceso al ejecutarse en formaindependiente (con recursos dedicados), para luego poder aplicarla en las metri-cas al ejecutarlo en forma simultanea. Por lo que, estas metricas ası definidas,no pueden ser utilizadas directamente para construir una heurıstica de adminis-tracion dinamica.

Por otro lado, en el trabajo realizado por Hsu et al. [15], se comparan distin-tas polıticas posibles para la administracion de una memoria cache compartida.Este las clasifica de la siguiente manera:

Capitalista: Es la polıtica sin administracion. Los recursos de la memoriacache compartida estan disponibles para todos los procesos, los cualescompetiran por estos sin restriccion alguna.

Utilitarista: Se busca maximizar el rendimiento de un proceso o grupomarcado como destacado, sin importar el resto de los procesos en ejecu-cion.

Comunista: El objetivo es lograr la mejor la equidad de recursos, asegu-rando que cada proceso obtiene la misma proporcion de estos, logrando unmejor rendimiento en su conjunto (teniendo como fundamento el corolariocitado anteriormente).

Como conclusion, expone la necesidad de adoptar un objetivo para ası selec-cionar y aplicar una polıtica de administracion, ya que cada una logra distintosniveles de rendimiento por tener objetivos distintos. Tambien, concluye que de-pendiendo del conjunto de benchmarks que se aplique, la polıtica Comunista ola Utilitarista seran una mejor que otra, mientras que la Capitalista no es bene-ficiosa bajo ninguna condicion (esto tambien es concluido en [36]). Finalmenteindica la necesidad de buscar una buena metrica para medir el rendimiento enforma dinamica para el modelo Comunista a fin de lograr el mejor rendimientoen conjunto.

26

3.3 Polıtica de administracion3 ADMINISTRACION DINAMICA DE


En la publicacion realizada por Zhou et al. [37] se realiza una mejora sobre losalgoritmos de administracion propuestos en [36]. Utilizando las mismas metricaspropuestas, el aporte brindado es el de clasificar los tiempos de acceso conside-randolos como privados o vulnerables segun se produzcan dentro de la seccionprivada o en la compartida de la jerarquıa. Ademas, destacan la necesidad deanadir nuevo hardware dedicado para realizar mediciones del comportamientode los procesos ejecutados sobre el nivel compartido de la jerarquıa de memoria,ya que el costo en recursos, espacio y complejidad de diseno son muy inferioresa la mejora obtenida en el rendimiento de estos.

Finalmente, Lin et al. [38], desarrolla una tecnica similar al Page-Coloring(Coloreo de Paginas), que utilizando un esquema hıbrido de recursos de hard-ware y software, le es posible administrar la cantidad de conjuntos de memoriacache asignados a un proceso en funcion de las referencias a memoria que esteposea, agrupandolos en conjuntos disjuntos llamados “Colores”. La contribucionbrindada es la de no tener un gran exceso (overhead) de recursos de hardwarepara administrar en forma dinamica el espacio otorgado a los procesos en eje-cucion.

Estos fueron los aportes tenidos en cuenta a la hora de desarrollar la heurısti-ca para la polıtica de administracion expuesta a continuacion.

3.3. Polıtica de administracion

Tomando los conocimientos expuestos en la seccion anterior, el objetivo de laheurıstica a desarrollar para la administracion dinamica de memorias cache com-partidas, es el de lograr el menor tiempo de ejecucion posible para el conjuntode procesos en ejecucion simultanea. Este objetivo debe ser alcanzado aplican-do la equidad en la administracion de los recursos (medidos como cantidad deconjuntos en la cache asignados para cada proceso), basadas en la polıticaspropuestas en [36, 37]. El aporte realizado en esta tesis, se basa en conocer eltipo de desacierto que produce cada proceso en tiempo de ejecucion, a fin declasificarlo y actuar en consecuencia variando el espacio otorgado en la memoriacache compartida a cada proceso, logrando una mejor equidad en la asignaciondel espacio con la consecuente mejora en el desempeno del conjunto de procesosen ejecucion.

3.3.1. Clasificacion de desaciertos D3C

La clasificacion de desaciertos segun 3C (detallada en la seccion 1.2.1) esconceptualmente clara e intuitiva, por lo que es utilizada ampliamente en la co-munidad cientıfica para realizar evaluaciones de desempeno. Sin embargo, poseela anomalıa de que en ciertos casos, da como resultado tasas de desaciertos deconflicto negativas, siendo de una interpretacion difıcil al momento de evaluaruna memoria cache. Estos casos se presentan cuando una memoria cache aso-ciativa por conjuntos tiene una menor tasa de desaciertos que una totalmenteasociativa. En el modelo 3C, al calcularse los desaciertos de conflicto, de hechose restan del total de referencias que fallan en la memoria cache bajo estudio, eltotal de referencias que fallan en la totalmente asociativa, independientementesi algunas de estas referencias aciertan en la memoria cache bajo estudio. Por lotanto, el valor negativo en una tasa de desaciertos de conflicto, implica que esmayor el numero de referencias que fallan en una cache totalmente asociativa y

27



aciertan en la cache bajo estudio. Un inconveniente adicional que se presenta,es el de no poder clasificar a los desaciertos de manera individual, ya que es unmodelo estadıstico.

Por este motivo en [6], se define el modelo Deterministic 3C o 3C Deter-minıstico, que utilizando la misma clasificacion de los desaciertos en Capacidad,Conflicto y Obligatorios, hace una redefinicion del concepto de cada uno:

“Un desacierto de Capacidad en el modelo D3C es toda referencia a memoriaque produce un desacierto no obligatorio en la cache bajo estudio, que ademasfalla en una totalmente asociativa con reemplazo LRU del mismo tamano. Elresto de los desaciertos no obligatorios se definen como desaciertos de conflic-to, es decir referencias que fallan en la cache bajo estudio y aciertan en unatotalmente asociativa del mismo tamano.”

Con esta nueva clasificacion, es posible determinar para cada referencia amemoria de un proceso, que tipo de desacierto es, a fin de modificar los recursosdisponibles para este, mejorando su rendimiento. Dada una cantidad de referen-cias a memoria C, si de esa cantidad un porcentaje mayoritario son desaciertosde Conflicto, serıa conveniente aumentar la asociatividad del cache donde seejecuta, dado que, una mayor asociatividad deriva en una disminucion de estos.Si en cambio la mayorıa son desaciertos de Capacidad, lo mas conveniente serıaaumentar la cantidad de bloques por vıa. Los desaciertos de tipo Obligatorio,pueden no ser considerados ya que son muy pocos en comparacion a los de-saciertos de Conflicto o Capacidad [7]. Ademas, de ser necesario, pueden serreducidos o incluso eliminados utilizando la tecnica conocida como prefetching[2].

3.3.2. Distancia de Pila LRU

La distancia de pila LRU para una referencia a un bloque de memoria dado,esta definida como el numero de referencias a bloques de memoria distintos quese realizaron desde la ultima referencia al mismo. Con esta definicion, se puededar una definicion operativa de la clasificacion D3C, expresada ya en [6]:

Dada una memoria cache de tamano igual a B bloques, y sea D la distan-cia LRU de una referencia a memoria que produce un desacierto, entonces eldesacierto se clasifica de la siguiente manera:

Obligatorios: D no computable.

Capacidad: D > B.

Conflicto: D ≤ B.

De esta forma, utilizando la clasificacion D3C junto con la distancia de pilaLRU, es posible clasificar los desaciertos de las referencias a memoria de unproceso, y segun una heurıstica, mejorar su desempeno.

La implementacion practica de la distancia de pila LRU fue expuesta porMattson et al. [39], que la publico para la evaluacion de distintas estrategias dereemplazo de memoria virtual utilizando pilas o stacks. La tecnica tuvo tanto

28



exito por su sencillez para ser aplicada en simulaciones que fue rapidamenteadoptada y utilizada por la comunidad cientıfica. El algoritmo, se aplica de lasiguiente manera:

“Cada acceso a memoria es ingresado en el tope de la pila cuando es refe-renciado, por ello los accesos anteriores a este seran desplazados un lugar haciael fondo de la pila. Si el acceso ya fue referenciado anterioremente se quita dellugar que ocupa en la pila y pasa a ocupar el lugar del tope, desplazando al restoun lugar hacia el fondo.”

Este es el algoritmo implementado en esta tesis y utilizado por la metricaexpuesta a continuacion.

3.3.3. Metrica para la evaluacion de la equidad de rendimiento

Dada la necesidad de evaluar la equidad en la asignacion de los recursos paracada proceso durante su ejecucion, se debe proveer la definicion de una metricaque determine el rendimiento efectivo de cada proceso segun sus recursos dememoria asignados y la tasa de desaciertos que este produzca en un intervalode tiempo (time slice) de ejecucion.

La metrica de la equidad en el rendimiento propuesta en [36] esta expresadaen la siguiente ecuacion.

TCompi

TDedi

=TCompj

TDedj

(6)

Esta es la medida de equidad para dos procesos i, j. El tiempo TCompi es el

tiempo de ejecucion insumido por el proceso i en un ambiente donde se com-parten recursos con el proceso j. TDed

i es el tiempo de ejecucion del proceso icon todos los recursos para si mismo. El analisis de los posibles valores de larelacion entre el tiempo de ejecucion compartido y dedicado nos indica que:

< 1. Es un valor no posible de alcanzar por esta metrica, ya que indicarıaque el tiempo de ejecucion con recursos compartidos es menor que el tiem-po de ejecucion con todos los recursos dedicados al proceso i.

= 1. Es el valor ideal a alcanzar para cada proceso. Esto indica que eltiempo de ejecucion con recursos compartidos es el mismo que el tiempode ejecucion con los recursos dedicados.

> 1. Son los valores normales obtenidos por la metrica. Esto indica queel tiempo de ejecucion con recursos compartidos es superior al tiempoalcanzado con recursos dedicados. Es claro el objetivo de minimizar estevalor para llevarlo a la situacion ideal, logrando ası el mejor desempenoposible del proceso.

De las variables que componen el calculo del tiempo de ejecucion, la adminis-tracion dinamica propuesta tiene por objetivo disminuir la tasa de desaciertos

29



de la memoria cache de tipo compartido, dejando invariante las demas variablesinvolucradas. Por ello, la ecuacion (6) puede ser expresada en funcion de la tasade desaciertos, como sigue:

DesaciertosCompi

DesaciertosDedi

=DesaciertosComp

j

DesaciertosDedj

(7)

Segun lo enunciado en [7], se concluye que incrementar la asociatividad perono el tamano de la memoria cache, reduce unicamente los desaciertos de Con-flicto, mientras que aumentar el tamano sin aumentar la asociatividad puedereducir los desaciertos de Conflicto y Capacidad. Esto es indicado tambien en[40] para los benchmarks de la SPEC CPU 2000. Con estos conceptos, la heurısti-ca propuesta debe otorgar la asociatividad total de la memoria cache, y paradisminuirla, evaluar si todos los procesos hacen uso de una menor asociativi-dad a la otorgada, o si necesidades externas como la reduccion del consumoenergetico lo requieren.

Entonces, la metrica para la equidad en el rendimiento aquı propuesta, tieneen cuenta lo previamente mencionado y se basa en la definicion operativa dela tecnica de distancia de pila LRU y el modelo D3C, descriptos en seccionesanteriores. Por lo que, la ecuacion (7) se reescribe como:

DesaciertosCompcapacidad i

DesaciertosDedcapacidad i

=DesaciertosComp

capacidad j

DesaciertosDedcapacidad j

(8)

En esta ecuacion vale el mismo analisis realizado para (6). Se busca que,para cada proceso, el valor de la fraccion sea lo mas cercano a la unidad paraası obtener el valor ideal de rendimiento. Un valor superior al ideal, indicara lanecesidad de asignar mas conjuntos de memoria cache al proceso para disminuirlos desaciertos de capacidad en un ambiente de ejecucion con recursos compar-tidos.

La expresion para multiples procesos en ejecucion de la ecuacion (8) quedadefinida por la expresion MEDCD: Metrica de Equidad en los Desaciertos deCache Determinıstica:

MEDCD =

N∑i

N∑j

∣∣∣∣∣DesaciertosCompcapacidad i

DesaciertosDedcapacidad i

−DesaciertosComp

capacidad j

DesaciertosDedcapacidad j

∣∣∣∣∣ (9)

La tecnica practica para la aplicacion de (9) se describe en la siguiente se-cuencia de pasos y en la figura 10:

30



1. Se define el tamano de la pila LRU igual a la cantidad de bloques quecompongan a la memoria cache. Tambien se ingresa una marca con lacantidad de bloques de memoria cache asignados al proceso a analizar.

2. Si una referencia a memoria que es desacierto no se encuentra en la pila,indicara un desacierto de Capacidad (u Obligatorio) de tipo Dedicado y ala vez de tipo Compartido.

3. Si la referencia a memoria se encuentra en la pila, y el valor de su distanciaLRU es superior a la marca antes realizada (que consiste en la cantidadde bloques de memoria cache asignados al proceso en ese instante) sera undesacierto de Capacidad de tipo Compartido.

4. Finalmente si la referencia a memoria se encuentra en la pila y el valor desu distancia LRU es inferior a la marca, indica un desacierto de Conflicto.

Pila LRU

Marca

Bloques asignadosal proceso

Cantidadtotal de bloques

de memoriacaché

compartida

Figura 10: Diagrama de Pila LRU para la aplicacion de la metrica (9).

Teniendo en cuenta el principio de localidad, es de esperar que esta metrica,sea conservada (o varıe en forma despreciable) en los sucesivos intervalos detiempos adoptados durante la ejecucion.

Para cumplir con el objetivo de lograr el mejor desempeno posible del con-junto de procesos en ejecucion, se debe minimizar el valor de la ecuacion (9)cada vez que se realice una administracion de la cantidad de conjuntos de memo-ria cache otorgado a cada proceso. Esta se realiza cada cierta cantidad fija deciclos de ejecucion, por lo que el objetivo de heurıstica a implementar puede serexpresado como:

|MEDCDadministracion i| < |MEDCDadministracion i−1| (10)

31



Queda por definir la variacion en la metrica (9) al quitarle o agregarle unacantidad dada de conjuntos de memoria cache segun conveniencia, en busca decumplir la ecuacion (10).

Al utilizar una tecnica similar al Page-Coloring para administrar el espaciootorgado a cada proceso, se crean zocalos que contienen un cierto numero fijode conjuntos de memoria cache, y son estos zocalos los que se intercambianentre los procesos al administrarlos. Cada zocalo contiene la informacion de lacantidad de accesos y desaciertos de capacidad de tipo compartido y de tipodedicado que tuvo en el periodo de tiempo de ejecucion previo a la aplicacionde la heurıstica de administracion.

Al quitarle un zocalo asignado a un proceso, se debe obtener el aumento enel valor de la metrica (8) para ese proceso. Este valor se obtuvo sumando losdesaciertos de tipo compartido (los desaciertos que tienen una distancia LRUsuperior a la cantidad de bloques de memoria cache asignada y menor al totalde bloques de la memoria cache compartida) del zocalo desasignado, al valortotal de desaciertos de tipo compartido, conservando el valor de la cantidadde desaciertos de tipo dedicado. Experimentalmente se pudo comprobar queeste valor calculado es una buena prediccion de la merma en el rendimiento delproceso al cual se le reduce el espacio disponible en memoria cache.

El calculo de la disminucion de desaciertos de capacidad (lo que produceun aumento de su rendimiento) para el proceso al cual se le asigna un nuevozocalo es menos preciso ya que este valor no puede ser determinado de una formasimple porque depende del uso (en cuanto a cantidad de accesos) que haga elproceso al cual se le asigna. La medida adoptada fue la de tomar el valor delzocalo con menos cantidad de desaciertos de tipo compartido. Por lo que, elvalor final calculado se obtiene de la resta de los desaciertos de tipo compartidode los zocalos disponibles con el valor de los desaciertos de tipo compartidodel zocalo con menos cantidad de desaciertos de tipo compartido, conservandoel valor de la cantidad de desaciertos de tipo dedicado. Si bien esto puede serobjetado indicando que puede ser mas preciso adoptar el promedio del total delos desaciertos de capacidad, o tomar los desaciertos del zocalo con menor omayor cantidad de accesos, los resultados de las pruebas realizadas indican quees una medida efectiva y de simple aplicacion practica.

La ultima consideracion a tener en cuenta es que, en ciertos casos, el valorde los desaciertos de tipo dedicado puede ser igual a 0. Esto puede ocurrirporque el proceso tuvo en su totalidad desaciertos de tipo compartido o inclu-so solo desaciertos de Conflicto, lo que ocasionarıa que los desaciertos de tipocompartido tambien sean igual 0. Para el primer caso, en el que los desaciertosde tipo dedicado sean igual a 0, se adopto que la metrica retornara el valor delos desaciertos de tipo compartido. La razon de esto es que si un proceso soloposee desaciertos de este tipo, se vera sumamente beneficiado con un aumentodel espacio, ya que la localidad de los datos es de un tamano igual o inferioral de la cache compartida. Si varios procesos estan en este estado, la metricaotorgara mas espacio al que poseea mayor cantidad de desaciertos. Para el se-gundo caso, se retorna 1, ya que al no tener desaciertos de tipo compartido nidedicados, indica el ideal para (8).

De esta manera quedan expuestas las metricas para la evaluacion del de-sempeno en ejecucion simultanea de los procesos utilizando la polıtica de ad-ministracion dinamica de la memoria cache compartida.

32



3.3.4. Heurıstica de administracion dinamica propuesta

La heurıstica para la administracion dinamica de memorias cache, toma laecuacion (10) enunciada en la seccion anterior y la aplica a todos los procesos enejecucion para administrar la cantidad de conjuntos de memoria cache (medidacomo cantidad de zocalos) que estos disponen. En la figura 11 se muestra lasecuencia de pasos que la componen:

ProcesoNuevo

Inicio

Si

No

3 4

ExisteInfo.

Accesos

No

Si

ProcesoNuevo

No

Si

2

5

Fin

1

Figura 11: Secuencia de la heurıstica de administracion dinamica.

1. Utilizando (8), se ordena a los procesos de mejor a peor rendimiento y selos ingresa ordenados como informacion a la heurıstica.

2. Al ingresar un proceso nuevo, es necesario otorgarle una cantidad de zoca-los inicial. Esta cantidad puede adoptarse como una proporcion de la can-tidad de conjuntos de la memoria cache bajo estudio o ser una cantidadfija arbitraria. Al no contar con informacion sobre los desaciertos de losprocesos ya en ejecucion (por no haberse ejecutado una cantidad acepta-ble de ciclos dentro del segmento de tiempo elegido), se quita un numeroproporcional de zocalos de memoria cache a estos para ser asignados alnuevo proceso.

33



3. La siguiente rama de la secuencia, cuenta con un nuevo proceso para otor-gar espacio en memoria cache y ademas, informacion de las metricas delos procesos ya en ejecucion. Al tenerlos ordenados de mejor a menorrendimiento, el primer proceso iterado debera otorgar la mayor cantidadde zocalos posibles al nuevo proceso. Si no se cumple con la cantidad dezocalos necesaria, se pasa al siguiente proceso en la lista ordenada hastacumplirla.

4. En esta seccion, se tiene que administrar unicamente a los procesos en eje-cucion. Se aplica para los procesos ordenados la metrica (9) para cumplirel objetivo de la heurıstica. Si con el intercambio de zocalos, se cumple conlo expresado en (10), se concreta efectivamente el intercambio de zocalos.

5. En este bloque, se busca analizar si los procesos involucrados hacen unuso intensivo de la asociatividad otorgada. Si la metrica para los desacier-tos de conflicto tiene un valor que esta por debajo de una constante dereferencia, se disminuira la asociatividad otorgada a todos los procesos.Esto impactara negativamente en el rendimiento ya que se disminuye eltamano y la asociatividad de la cantidad de memoria cache.

En el siguiente capıtulo se detalla el ambiente de simulacion utilizado parala evaluacion de la polıtica de administracion dinamica desarrollada. Este repro-duce los requisitos de hardware necesarios a fin de obtener informacion lo masrealista posible para el calculo de la metrica (9) para desaciertos de Capacidady Conflicto, en la busqueda de lograr el objetivo de la heurıstica expresado enla ecuacion (10).

34

4 AMBIENTE DE SIMULACION

Capıtulo 4

4. Ambiente de Simulacion

4.1. Simulador de Jerarquıas deMemoria Cache

Para la simulacion de la administracion dinamica de memorias cache com-partidas, se utilizo el modulo descripto en la seccion 2.2. Para realizar simula-ciones lo mas realistas posibles a fin de validar los resultados de equidad y de-sempeno logrados por la heurısitca propuesta se decidio implementar en dichosimulador los siguientes componentes de hardware descriptos a continuacion.

4.1.1. Componentes de Hardware simulados

En la figura 12, se da una descripcion tecnica y operativa de cada componentedel modulo simulador de jerarquıas de memoria.

1. Organizacion: Es el componente principal del simulador. Es donde el Con-trolador de Procesos ingresara las instrucciones obtenidas de la instru-mentacion a traves de la Pintool. Al crear un componente organizacion, sele debe indicar la cantidad de nucleos a simular, y la cantidad de nucleosque comparten el ultimo nivel de memoria de la jerarquıa. Este ultimo,si es 1 indica que el ultimo nivel es privado para cada nucleo creado y sepuede incrementar hasta el mismo valor de la cantidad de nucleos simu-lados resultando en que el ultimo nivel de la jerarquıa es compartido portodos. Los valores intermedios representan que el ultimo nivel es compar-tido por cierta cantidad de nucleos (por ejemplo una organizacion con 4nucleos puede compartir el ultimo nivel de memoria entre 2 de los nucleos).

2. Nucleo: Esta compuesto por una cache de nivel 1 de tipo split de datos eintrucciones de igual configuracion. El nivel 2 por una cache de tipo unifi-cada y privada para cada nucleo, y el tercer nivel, por una cache de tipounificada que puede ser privada o compartida. Los niveles 2 y 3 puederser anulados para simular jerarquıas de menor cantidad de niveles. Al ins-tanciar este componente se le indica: un numero de nucleo para poder seridentificado, componentes cache para los 3 niveles y la cantidad maximade instrucciones que puede ejecutar por ciclo ya que se simula un proce-sador superescalar. Durante la ejecucion de la simulacion, se le creara uncomponente proceso, en el cual se ingresara la informacion de la ejecucionrealizada. Se simula un nucleo con un solo hilo de ejecucion, es por elloque por cada nucleo de simulacion se ejecutara un solo proceso durantetoda la simulacion, siendo el componente Organizacion el encargado deesta asignacion.

3. Cache: Representa una memoria cache de tipo privado para la jerarquıa yesta compuesta por un conjunto de vıas. Al ser creada por el componen-

35

4.1 Simulador de Jerarquıas deMemoria Cache 4 AMBIENTE DE SIMULACION

7 -

Adm

inis

trad

orT

intin

g P

age

Col

orin

g

16 -

Bib

liote

ca

5 -

Blo

que

3 -

Cac

hé

6 -

Cac

héC

ompa

rtid

a12

- C

lock

17 -

Def

inic

ione

s

13 -

Exc

eptio

n

10 -

Has

hIn

dexa

do9

- Ín

dice

Col

umna

s

8 -

Info

rmac

ión

Núc

leo

15 -

Inst

rucc

ión

11 -

LR

U S

tack

2 -

Núc

leo

1 -

Org

aniz

ació

n

14 -

Pro

ceso

4 -

Vía

Figura 12: Diagrama de componentes del Simulador de Jerarquıas de Memoria.

36


te Organizacion, se le configuran los siguientes parametros: cantidad maxi-ma de accesos no bloqueantes, tamano total, cantidad de vıas, nivel en lajerarquıa, tamano de bloque y un nombre para poder identificarla. Op-cionalmente se le pueden indicar una cantidad de ciclos para los aciertosy desaciertos. Si estos no son configurados se tomaran los estipulados pordefecto en el componente Definiciones. Las caracterısticas no configurablesson: polıtica de reemplazo LRU y de tipo Write-Back.

4. Vıa: Representa a una vıa del componente Cache. Esta compuesta por unconjunto de bloques. Posee las funciones para acceder y buscar los bloquesque la componen.

5. Bloque: Representa a un bloque del componente Vıa. Este guarda el rotulo(tag) de la direccion accedida ası como el numero de ciclo de acceso parasaber, comparando los ciclos de ejecucion, si es un bloque a ser reemplaza-do, ya que los bloques mas recientemente accedidos tendran un ciclo deactualizacion mayor.

6. Cache Compartida: Representa al ultimo nivel de la jerarquıa. Esta in-tegrada por los mismos elementos que el componente Cache por lo que sele ingresa la misma informacion de configuracion inicial, junto con la adi-cion del componente Administrador, que es el encargado de administrarel espacio que ocupa cada proceso en ejecucion. Puede ser administradasegun la polıtica desarrollada en esta tesis o en forma Capitalista (sinadministracion) variando la configuracion en el componente Definiciones.

7. Administrador: Es el componente encargado de aplicar la administraciondinamica del ultimo nivel de la jerarquıa simulada. Para ello, cada accesoal ultimo nivel de esta es previamente informado a este componente, paracalcular las metricas necesarias de cada proceso y aplicar la heurıstica deadministracion dinamica elegida.

8. Informacion Nucleo: Como el componente Administrador debe conocer lainformacion de todos los procesos en ejecucion, este componente es el en-cargado del calculo de las metricas utilizando el componente LRU Stack,de la conversion de direcciones reales en las mapeadas para ocupar siemprelos conjuntos de memoria cache que le corresponde al proceso utilizandoel componente Hash Indexado, ası como tambien, llevar la cuenta de lacantidad de accesos de cada vıa (mediante el componente Indice Colum-nas).

9. Indice Columnas: Es el componente encargado de llevar cuenta de la canti-dad de accesos a cada vıa por proceso. Esto sirve para conocer si un procesoaccede mas intensivamente a un conjunto de vıas que a otro, ası como tam-bien, para determinar si es posible reducir la asociatividad de la memoriacache compartida.

10. Hash Indexado: Este componente es el encargado de convertir cada direc-cion que un proceso en ejecucion accede, en una direccion que mapee en losconjuntos de memoria cache compartida que le corresponde segun los zoca-los asignados por el componente Administrador. Esto evita el problemade desaciertos inter-procesos ya que cada proceso tiene zocalos disjuntos

37


asignados en la memoria cache compartida y ademas permite la adminis-tracion del espacio (como cantidad de zocalos). Esta compuesto por unatabla, donde se encuentran los ındices de los zocalos posibles a accederen memoria cache. Como el ındice de un zocalo es menor al ındice deun conjunto de memoria cache, en cantidad de bits, esto da la posibili-dad de sectorizar la memoria cache en zocalos (colores en la tecnica dePage Coloring) disjuntos con distinta cantidad de conjuntos de memoriacache cada uno. Con este enfoque se da la aparicion de alising homonimo(sucede cuando dos procesos usan la misma direccion virtual para accedera lugares fısicos distintos) y al utilizar memorias cache virtualmente in-dizadas y virtualmente taggeadas ocurren los sinonimos (direcciones vir-tuales distintas refieren a un mismo lugar fısico). La solucion de estosproblemas en la implementacion del simulador y en el hardware real esabordada en la seccion 4.2.3.

11. LRU Stack: Implementa el algoritmo de distancia de pila LRU con lavariacion de tener un tamano maximo fijado por la cantidad de bloquesde memoria cache asignado al proceso en el intervalo de tiempo de ejecu-cion, junto con la marca de cantidad de bloques asignados en ambiente deprocesos compartidos. Este componente es el encargado de actualizar losvalores de la cantidad de desaciertos de conflicto y capacidad/obligatorios.Sus contadores, ası como el valor de la marca del tamano de memoriacache asignado, son configurados al inicio de cada intervalo de ejecucionluego de ser aplicada la heurıstica de administracion por el componenteAdministrador. Los valores de los contadores son inicialados en 0 y ala marca del tamano se le asigna el valor de la cantidad de conjuntos dememoria cache asignados al proceso luego de aplicada cada administracion.

12. Clock: Es el encargado de simular los ciclos de reloj de la organizacion. Estecomponente da la referencia de los ciclos de ejecucion de las instruccionesingresadas a la jerarquıa para cada proceso.

13. Excepcion (Exception): Este componente permite ver en forma clara ysencilla, cualquier tipo de error ya sea de configuracion inicial de alguncomponente (por ejemplo una vıa de memoria cache con una cantidad debloques no potencia de 2) hasta los errores en tiempo de ejecucion quepuedan producirse.

14. Proceso: Guarda registro de los valores obtenidos de la ejecucion de lasinstrucciones de un proceso. Aquı se registra la tasa de desaciertos encada nivel de la jerarquıa, los ciclos de inactividad (stalls), los ciclos deejecucion y la cantidad de accesos a memoria. Esta informacion es la queluego se enviara al informe de salida del simulador.

15. Instruccion: Encapsula la funcionalidad de la ejecucion de una instruc-cion en el simulador. Al ser un simulador de un procesador superescalar,este componente se encarga de detectar y administrar las dependencias dedatos RAW (Read After Read), WAR (Write After Read), WAW (WriteAfter Write) que pueden suceder en las instrucciones con acceso a memoriade datos, ejecutadas simultaneamente en un mismo nucleo. Una instruc-cion con dependencias de datos ingresada para su ejecucion en un momen-

38

4.2 Aspectos de la implementacionde componentes 4 AMBIENTE DE SIMULACION

to posterior, no sera ejecutada hasta que la instruccion que le precede setermine de ejecutar completamente.

16. Biblioteca: Este componente agrupa funciones que pueden ser utilizadaspor todos los componentes, como ser funciones de conversion binario-hexadecimal, calculos matematicos y de validacion de parametros.

17. Definiciones: Es este componente se indican las constantes de configu-racion por defecto del simulador.

4.2. Aspectos de la implementacionde componentes

A continuacion se mostraran los aspectos mas relevantes de la implementacionde las tecnicas descriptas en las secciones anteriores, que fueron adoptados enel desarrollo del simulador de jerarquıas de memoria.

4.2.1. Tinting

Tinting es la tecnica conocida para administrar el espacio de memoria cacheasignado a un proceso, variando la cantidad de vıas disponibles para este. Fuedesarrollada en [41] y es la base de la propuesta de Columnizacion expuestaen la seccion 3.2. En el simulador de jerarquıas de memoria fue implementadautilizando una lista con un contador por cada vıa por cada proceso en ejecucion,siendo su implementacion en hardware real de muy bajo costo al utilizar uncontador para cada vıa.

4.2.2. LRU Stack

En los procesadores reales se utilizan estructuras de arboles binarios paracalcular la llamada distancia Pseudo-LRU como una aproximacion de la distan-cia LRU real. Si bien esta tesis hace uso de los valores reales de distancias LRU,la heurıstica y metricas propuestas seran menos precisas pero igualmente apli-cables al utilizar la distancia Pseudo-LRU. El mayor problema a resolver paraeste componente es la cantidad de hardware necesario para su implementacionreal. En [42], se expone una nueva estructura capaz de mejorar en hasta 26 %la eficiencia de almacenamiento respecto de la utilizada actualmente. Asimis-mo, en [43], se hace uso de la prediccion de la distancia de reuso LRU. Ladistancia de reuso de una direccion dada es definida como el numero de eventosintervinientes (como nocion de tiempo) entre dos referencias consecutivas a esadireccion. Se utiliza como “evento” cada referencia que es ingresada a la memo-ria cache. Su implementacion en hardware requiere menos componentes que lautilizada para Pseudo-LRU y los valores obtenidos por el predictor de distanciade reuso pueden ser utilizados con las metricas aquı definidas, quedando comotrabajo futuro la evaluacion de los resultados al aplicarla.

4.2.3. Page Coloring y Hashing de direcciones

Dado el funcionamiento de PIN y la Pintool desarrollada, las direcciones delos accesos obtenidos son de tipo virtual para todos los procesos instrumentados.Esto significa que el simulador debe contemplar la duplicidad de las direcciones

39


al ingresar en la jerarquıa y simular memorias cache virtualmente taggeadas(esto es, que se compara el tag de una direccion virtual para saber si es aciertoo no) y virtualmente indexadas (se compara el ındice de una direccion virtualpara indizar a la memoria cache). Con estas caracterısticas de simulacion se da elaliasing homonimo de direcciones, que significa que dos procesos distintos usanla misma direccion virtual para acceder a lugares fısicos distintos en la memoria.Al utilizar el identificador de proceso (PID) se identifica unıvocamente cadadireccion de cada proceso que accede a la jerarquıa de memoria, solucionandoeste problema tanto en el hardware real como en el simulador.

El uso del componente “Hash Indexado” utilizando direcciones virtuales, dala posibilidad de asignar direcciones con igual tag pero distinto ındice ocasio-nando un solapamiento en un mismo conjunto de la memoria cache (fenomenoconocido como sinonimos de direcciones), que en el simulador fue solucionadomodificando la cantidad de bits utilizada en la comparacion de tags en la memo-ria cache compartida. Se utilizo como tag de comparacion el tag + el ındice dela direccion original a traducir.

Finalmente, en [38], se desarrolla una mejora de la tecnica de Page-Coloring,que consiste en aplicar una mascara al traducir las direcciones virtuales en fısicaspara luego ser ingresadas en una memoria cache fısicamente taggeada. Se muestrala capacidad de crear en una cache de 4MB hasta 32 colores (o zocalos) conpaginas virtuales de 8KB. Su enfoque se aplico a la heurıstica aquı desarrollada,administrando el espacio que cada proceso ocupa en las regiones definidas porla agrupacion de colores creada por el Page-Coloring en forma de los zocalosantes mencionados.

4.2.4. Arquitectura simulada

La arquitectura utilizada para la simulacion de los conjuntos de prueba deta-llados en la seccion 4.4 es la siguiente:

2 nucleos.

L1 de instrucciones privada de 32KB, 4 vıas y 64B por bloque. 1 ciclo paralos aciertos.

L1 de datos, privada de 32KB, 4 vıas y 64B por bloque. 1 ciclo para losaciertos.

L2 unificada, privada de 256KB, 8 vıas y 64B por bloque. 7 ciclos para losaciertos.

L3 unificada y compartida para todos los nucleos. 2MB, 16 vıas y 64B porbloque. 20 ciclos para los aciertos.

Tiempo de acceso a memoria principal de 380 ciclos.

4 instrucciones en ejecucion paralela por nucleo.

50 ciclos de tiempo de tiempo de administracion (si es que es aplicada).

300000 ciclos ejecucion entre administraciones (time slice).

40


32K

B

4 V

ías

64B

ytes

T. B

loqu

eIn

stru

ccio

nes

32K

B

4 V

ías

64B

ytes

T. B

loqu

eD

atos

256K

B

8 V

ías

64B

ytes

T. B

loqu

eU

nific

ada

Núc

leo

1

32K

B

4 V

ías

64B

ytes

T. B

loqu

eIn

stru

ccio

nes

32K

B

4 V

ías

64B

ytes

T. B

loqu

eD

atos

256K

B

8 V

ías

64B

ytes

T. B

loqu

eU

nific

ada

Núc

leo

2

2MB

16

Vía

s64

Byt

es T

. Blo

que

Uni

ficad

aC

ompa

rtid

a

Mem

oria

Prin

cipa

l

NIV

EL

1N

IVE

L 2

NIV

EL

3N

IVE

L 4

Figura 13: Esquema de la arquitectura utilizada para la simulacion.

41

4.3 Seleccion de los benchmarksa utilizar 4 AMBIENTE DE SIMULACION

Con esta configuracion se procedio a ejecutar cada uno de los benchmarks,agrupados como conjuntos de prueba, detallados en la seccion 4.4. La eleccionde esta arquitectura y los valores de los parametros iniciales adoptados en lasimulacion fueron determinados por distintos factores. En [36], se simulo unajerarquıa de memoria de 2 niveles, siendo el primer nivel de datos e instruccionesde 32Kb de tamano, 4 vıas y 64B de tamano de bloque con 3 ciclos para losaciertos. El nivel 2, de tipo compartido, con 512Kb de tamano, 8 vıas y 64B detamano de bloque con 14 ciclos para los aciertos. El tiempo de acceso a memo-ria utilizado fue de 407 ciclos. En [37], se obtuvieron los resultados simulandouna arquitectura identica a la utilizada en [36], pero aumentando el tamanode la memoria cache de segundo nivel a 1MB con 12 ciclos para los aciertos ydisminuyendo la latencia del acceso a memoria principal a 400 ciclos.

Teniendo en cuenta las configuraciones de jerarquıas de memoria expuestasen la tabla 1.2.3 y la necesidad de evaluar el comportamiento de la polıtica de ad-ministracion dinamica propuesta de la forma mas realista posible, se adopto si-mular una jerarquıa de mayor nivel que las utilizadas en [36, 37] ya que secorresponde con las jerarquıas implementadas en los procesadores desarrolladosactualmente. Ademas se duplico el valor del tamano de memoria cache compar-tida y se disminuyo el valor del tiempo de acceso a memoria principal por elmismo motivo expuesto anteriormente.

4.3. Seleccion de los benchmarksa utilizar

Los benchmarks para realizar la evaluacion del ambiente de desarrollo, ası co-mo las hipotesis propuestas en esta tesis, debıan cumplir con las siguientes condi-ciones:

1. Ser de tipo entero para no complejizar el desarrollo de la Pintool de ins-trumentacion.

2. Tener distinta localidad de datos, ası como variaciones de esta a lo largode su ejecucion.

3. Ser posibles de reproducir sin necesidad de pedir licencias especıficas.

4. Ser utilizados por la comunidad cientıfica para objetivos similares a lospropuestos.

Por estos motivos es que se decidio utilizar los benchmarks de tipo entero dela SPEC CPU 2006 [24]. En el sitio web oficial de esta entidad se describe cadauno en forma detallada, ası como el conjunto de datos de entrada y la salida.

De todos los benchmarks disponibles se eligieron los siguientes:

Gcc.

Libquantum.

H.264.

En el trabajo realizado en [29], se analiza el consumo de memoria de losbenchmarks: Bzip2, Sjeng, Astar, Libquantum y Gcc. En dicho trabajo se ejecutaa los benchmarks en forma independiente para tener una referencia de consumo

42

4.4 Clasificacion como conjuntosde prueba 4 AMBIENTE DE SIMULACION

y luego en forma simultanea junto con varias instancias del benchmark Mcf. Seejecutan varias instancias de este ultimo benchmark para ası ocupar mas espacioen la memoria cache, y que los benchmarks de interes (los antes nombrados)compitan por el espacio de memoria cache con las instancias creadas de Mcf. Eltrabajo realizado por el benchmark Mcf, podrıa realizarse con el modelo de lazosimple (utilizado en esta tesis para realizar las pruebas unitarias de integraciondel simulador de jerarquıas), pero su uso para tales fines se considero como unainterfencia innecesaria, ya que el objetivo principal es administrar el espaciootorgado en la memoria cache de tipo compartido a los benchmarks que sonconsiderados como representativos del general de las aplicaciones y no para unconsumidor masivo de memoria.

4.3.1. Gcc

El benchmark consiste en compilar codigo preprocesado utilizando la colec-cion de compiladores Gcc. El preprocesador de codigo es llamado al principio delproceso de compilacion. El preprocesado consiste en manejar las directivas delcodigo fuente como ser los #include, #if, etc. El benchmark toma como entradael archivo preprocesado y lo compila.

Como entrada se utilizo el archivo g23.i que es el conocido programa fold-const.c utilizado tambien como entrada para otros benchmarks.

4.3.2. Libquantum

Libquantum es una biblioteca para la simulacion de una computadora cuanti-ca. Estas, estan basadas en los principios fısicos de la mecanica cuantica y seutilizan para resolver ciertas tareas que serıan sumamente costosas utilizando losalgoritmos normales. El benchmark consiste en factorizar un numero utilizandoel algoritmo Shor dentro de la biblioteca Libquantum.

Como entrada se ingreso el numero primo 1397 y se lo factorizo utilizando8 qubits [44] (un qubit es el equivalente a un bit en la mecanica cuantica. Laprincipal diferencia consiste en que un qubit puede tener los estados 1, 0 o 1 y0 a la vez).

4.3.3. H.264

H.264 consiste en tomar un video en formato yuv y comprimirlo utilizando elcompresor de video H.264/AVC (Advance Video Coding) [45]. El video en forma-to yuv, tambien conocido como YCrCb, es un modelo de representacion de colorde video analogico. Consiste en la transmision de video con los componentes devideo (crominancia y luminosidad) en forma separada. Es usado en las normasPAL y SECAM. Como entrada se utilizo el archivo de video Foreman baseline,corriendo a 300 cuadros por segundo y con una resolucion de 352x288 pixeles.La salida es el video comprimido en formato H.264 junto con los archivos deinformacion sobre la compresion.

4.4. Clasificacion como conjuntosde prueba

Para poder verificar la heurıstica desarrollada para la administracion dinami-ca de memorias cache compartidas, se deben ejecutar a los benchmarks antes

43

4.5 Resultados de las simulaciones 4 AMBIENTE DE SIMULACION

descriptos en forma simultanea; ya que como cada uno posee distinta localidadde datos y a su vez esta varıa a lo largo de la ejecucion, se podra evaluar elcomportamiento de la heurıstica bajo distintas condiciones.

Se ejecutaron 1000 millones de instrucciones de cada benchmark sin ser ins-trumentadas. Luego se ejecutaron 200 millones de instrucciones y se evaluaronlos resultados obtenidos. Esto se realiza habitualmente para evitar medir losefectos de las cargas de las bibliotecas requeridas al inicio de la ejecucion de losbenchmarks y ademas para situarlos en un estado arbitrario de ejecucion paraque los resultados obtenidos sean mas objetivos.

Los conjuntos para realizar la evaluacion del desempeno de las polıticas deadministracion son:

4.4.1. Conjunto A - H.264, Libquantum

Libquantum tiene una localidad de datos mucho menor que H.264. Se es-pera que la heurıstica elimine los desaciertos de inter-procesos entre estos dosbenchmarks y ademas pueda detectar la mayor localidad de los datos de H.264,otorgando la cantidad necesaria de espacio a la velocidad necesaria a este bench-mark, para lograr un aumento en su desempeno. Respecto a Libquantum, altener una localidad de datos muy inferior a los valores de memoria cache uti-lizados en la simulacion, es de esperar que se le asigne una cantidad de espaciosuperior a H.264, pero sin esperar una mejorıa sustancial en su desempeno.

4.4.2. Conjunto B - Gcc, Libquantum

Gcc tiene una menor localidad de datos y a su vez una mayor variacion deesta respecto de H.264. Se espera cumplir el mismo objetivo que para el conjuntode prueba A, esperando que la heurıstica pueda responder a las variaciones dela localidad de datos de Gcc de manera eficiente.

4.4.3. Conjunto C - Gcc, H.264

En este conjunto de prueba, se tienen a los dos benchmarks con mayor lo-calidad de datos. El objetivo a cumplir por la heurıstica es que pueda detectaren forma eficiente las variaciones en la tasa de accesos a memoria principal yademas a la velocidad necesaria para producir una mejora en el desempeno deambos benchmarks.

4.5. Resultados de las simulaciones

En la busqueda por lograr el objetivo principal de la polıtica de adminis-tracion propuesta, se ven afectados distintos parametros para la medida deldesempeno de los procesos en ejecucion. Es por ello que se tomaron en cuentadistintas metricas para analizar los resultados de las simulaciones obtenidas. Lasmetricas utilizadas para estos fines fueron:

1. Tasa de desaciertos en memoria cache compartida: Esta es una metricafundamental para evaluar el desempeno de una memoria cache y ademases simple de medir en tiempo de ejecucion.

44


2. Instrucciones Por Ciclos (IPC): Esta metrica indica directamente el de-sempeno logrado por el proceso. A mas instrucciones por ciclos, mejordesempeno logrado. Para un programa de un tamano determinado, porejemplo de ciclos iterativos (loops), el IPC se corresponde directamentecon el desempeno efectivo del proceso.

3. Ancho de banda utilizado: Definida como la cantidad de accesos a memoriaprincipal por ciclos de ejecucion. Es una metrica que se considera impor-tante ya que el ancho de banda sera un recurso fundamental en los futurosCMP.

Estas tres metricas propuestas se compararon con la polıtica de adminis-tracion Capitalista que es la utilizada como referencia en los trabajos relaciona-dos.

4.5.1. Tasa de desaciertos en memoria cache compartida

Los primeros resultados a analizar corresponden a la tasa de desaciertosobtenida bajo la administracion dinamica propuesta y la administracion Capi-talista. Se busca minimizar la cantidad de desaciertos ya que estos conllevanpenalidades muy elevadas que producen una disminucion en el IPC.

Para cada conjunto de prueba evaluado se muestran tres figuras. La primera,corresponde a la tasa de desaciertos en la memoria cache compartida para cadaproceso en forma individual, la siguiente muestra la distribucion de zocalos paracada proceso realizada por la administracion dinamica propuesta, mientras quela ultima figura, muestra la tasa de desaciertos global del conjunto de pruebaanalizado.

Para el conjunto de prueba A, puede observarse una disminucion continuade la tasa de desaciertos hasta el ciclo de ejecucion 33M, a partir del cual, entraen un estado normalizado. Esto es producto de la cantidad de accesos necesariospara la estabilizacion de la memoria cache compartida. Estos primeros desacier-tos pueden ser tomados como de tipo Obligatorio, por lo que puede asumirseque a partir del ciclo de ejecucion 37M la memoria cache compartida entra enestado de “regimen” de ejecucion. Luego del ciclo de ejecucion 40M la heurısticaaquı desarrollada comienza a diferenciarse de la Capitalista, al eliminar los de-saciertos de tipo inter-procesos y ademas otorgando el espacio necesario a cadabenchmark. Por lo que, al ser H.264 el benchmark con mayor localidad de datosy no tener interferencias con Libquantum, su tasa de desaciertos disminuye,mientras que Libquantum al tener una localidad de datos inferior y a su vez,ver restringido su espacio disponible, su tasa de desaciertos aumenta. Los de-saciertos de tipo inter-procesos representaron el 34,4 % del total de desaciertosproducidos en la memoria cache compartida bajo la administracion Capitalistay del 0 % bajo la administracion propuesta.

45


10

20

30

40

50

60

70

80

90

100

0 20 40 60 80 100 120

Tas

a de

des

acie

rtos

[%]

Ciclos de ejecución [M]

Tasa de desaciertos de H264 y Libquantum

H264 − CapitalistaLibquantum − Capitalista

H264 − Adm. PropuestaLibquantum − Adm. Propuesta

Figura 14: Tasa de desaciertos para el conjunto de prueba A.

Segun la informacion obtenida luego de la simulacion, Libquantum ter-mino ocupando un 51,6 % del espacio y H.264 el 48,4 % restante en la memoriacache compartida. Cada zocalo creado agrupa dos conjuntos de la memoriacache compartida simulada. Esto resulta en un tamano de 2KB por zocalo. Deesta forma, se concluye que la heurıstica le otorgo mas espacio al benchmarkLibquantum, que tiene una localidad de datos menor que H.264, pero a esteultimo le asigno el espacio necesario para que su desempeno sea el optimo segunlas metricas aplicadas en la heurıstica.

495

500

505

510

515

520

525

530

80 85 90 95 100

Can

tidad

de

zóca

los


Distribución de zócalos de H264 y Libquantum

H264Libquantum

Figura 15: Distribucion dinamica de zocalos para el conjunto de prueba A.

46


Respecto a la tasa de desaciertos global para este conjunto de prueba, puedeobservarse que la restriccion del espacio, al ser separado en zocalos disjuntos,no incidio en un aumento en la tasa de desaciertos para los primeros ciclos deejecucion (la heurıstica no realizo reasignaciones), y que al comenzar la adminis-tracion del espacio, es donde la tasa de desaciertos global comienza a disminuir.La maxima reduccion de los desaciertos globales fue del 20 %.

30

40

50

60

70

80

90

100

0 20 40 60 80 100 120

Tas

a de

des

acie

rtos

[%]


Comparación de la Tasa de Desaciertos Total de H264 y Libquantum

CapitalistaAdm. Propuesta

Figura 16: Tasa de desaciertos global para el conjunto de prueba A.

Si bien la tasa de desaciertos de H.264 disminuye y la de Libquantum au-menta, tomado en forma global, puede verse el beneficio logrado aplicar la ad-ministracion dinamica a la memoria cache de tipo compartido.

El analisis del conjunto de prueba B, muestra que se requiere una cantidadde ciclos de ejecucion similar a los del conjunto A para la entrada en regimende la memoria cache. Para la tasa de desaciertos individual de cada benchmark,puede observarse el mismo efecto que en el conjunto de prueba A, pero lograndouna mejora inferior en la tasa de desaciertos del benchmark Gcc, y conservandoel rango de aumento de esta tasa para Libquantum, respecto de los valoreslogrados al ejecutar el conjunto de prueba A. Esto es producto de que Gcc tiene67,2 % mas accesos a la memoria cache compartida que H.264, lo que resulta enuna tasa de desaciertos de tipo inter-procesos del 35,5 % para este conjunto deprueba al utilizar la polıtica de administracion Capitalista y del 0,2 % bajo laadministracion propuesta.

47


0

10

20

30

40

50

60

70

80

90

100

0 20 40 60 80 100 120

Tas

a de

des

acie

rtos

[%]


Tasa de desaciertos de Gcc y Libquantum

Gcc − CapitalistaLibquantum − Capitalista

Gcc − Adm. PropuestaLibquantum − Adm. Propuesta

Figura 17: Tasa de desaciertos para el conjunto de prueba B.

Esta ultima, termina otorgando menos espacio a Gcc del que le asigno aH.264, ya que el primero logra una mayor localidad de datos a partir del ciclode ejecucion 85M, mientras que Libquantum al tener una localidad de datossumanente inferior al tamano de la memoria cache compartida simulada, nologra obtener un beneficio apreciable al tener mayor espacio del que obtuvo enel conjunto de prueba A. La maxima reduccion de la tasa de desaciertos globalpara este conjunto de prueba fue del 11 %.

25

30

35

40

45

50

55

60

65

70

0 20 40 60 80 100 120

Tas

a de

des

acie

rtos

[%]


Comparación de la Tasa de Desaciertos Total de Gcc y Libquantum


Figura 18: Tasa de desaciertos global para el conjunto de prueba B.

48


La asignacion de zocalos por parte de la administracion dinamica para esteconjunto de prueba, afirma lo concluıdo al analizar la tasa de desaciertos de ca-da benchmark en forma individual. Ademas de asignar el espacio en la memoriacache de forma eficiente, la tasa de asignacion de espacio logra adaptarse lo sufi-cientemente rapido a los cambios de localidad de datos del conjunto de prueba.Esto se aprecia al ver que la variacion del espacio asignado tiene una tasa decambio (medida como cantidad de zocalos cada millon de ciclos de ejecucion)superior a la del conjunto de prueba A.

470

480

490

500

510

520

530

540

550

60 70 80 90 100 110 120

Can

tidad

de

zóca

los


Distribución de zócalos de Gcc y Libquantum

GccLibquantum

Figura 19: Distribucion dinamica de zocalos para el conjunto de prueba B.

4.5.2. Instrucciones por ciclos (IPC )

La comparacion de la metrica del IPC de un proceso ejecutado bajo lapolıtica de administracion propuesta y entre la polıtica Capitalista da una pro-porcion del incremento en la mejora en el desempeno. Este incremento puedeser calculado utilizando la siguiente expresion:

Mejora del Rendimiento =IPCadm.din.

IPCadm.cap.(11)

El analisis de esta metrica para el conjunto de prueba A, indica que ladisminucion en la tasa de desaciertos del benchmark H.264 se ve claramentereflejada en un aumento de su IPC, mientras que para Libquantum, el aumentoen la tasa de desaciertos no incide en su desempeno en forma considerable. Lamejora maxima lograda para el benchmark H.264 fue del 10 %, mientras que ladisminucion maxima del desempeno para Libquantum fue del 3 %.

El desempeno, visto en forma global para este conjunto de prueba, muestraque se logro una mejora maxima del 2,35 %. Esto indica que mejorar o empe-orar el desempeno individual de un proceso en ejecucion no redunda en forma

49


1.3

1.4

1.5

1.6

1.7

1.8

1.9

0 20 40 60 80 100 120

IPC


Comparación del IPC de H264 y Libquantum

H264 − CapitalistaLibquantum − Capitalista

H264 − Adm. PropuestaLibquantum − Adm. Propuesta

Figura 20: IPC para el conjunto de prueba A.

proporcional en el desempeno del conjunto. Finalmente, se observa que los re-sultados obtenidos cumplen con el corolario enunciado en [36], el cual indica quemejorar la equidad en la administracion de los recursos, redunda en un aumentodel desempeno de la ejecucion global en ambientes de multi-procesos.

3.15

3.2

3.25

3.3

3.35

3.4

3.45

3.5

3.55

3.6

3.65

0 20 40 60 80 100 120

IPC


Comparación del IPC TOTAL de H264 y Libquantum


Figura 21: IPC global para el conjunto de prueba A.

Para el conjunto de prueba B, el benchmark Gcc se ve beneficiado por laadministracion dinamica propuesta ya que se administra su espacio en formaeficiente y a una velocidad acorde a la del cambio en su localidad de datos.

50


Sin embargo, esta es menor a la obtenida por H.264 ya que la localidad dedatos de H.264 tiene una menor variacion a lo largo del tiempo de ejecucion.

1.64

1.66

1.68

1.7

1.72

1.74

1.76

1.78

1.8

1.82

1.84

0 20 40 60 80 100 120

IPC


Comparación del IPC de Gcc y Libquantum

Gcc − CapitalistaLibquantum − Capitalista

Gcc − Adm. PropuestaLibquantum − Adm. Propuesta

Figura 22: IPC para el conjunto de prueba B.

Al Gcc aumentar su localidad de datos a partir del ciclo de ejecucion 85M,se le disminuye la cantidad de zocalos asignados con la consecuente merma ensu desempeno, en beneficio del de Libquantum. En cuanto a este ultimo, ladisminucion en su IPC es del 2,6 %, siendo sensiblemente menor a la producidaen la ejecucion del conjunto de prueba A.

El analisis de la metrica del IPC global de este conjunto de prueba muestraun aumento considerable a partir de la entrada en estado de regimen de usode la memoria cache compartida. La mejora maxima respecto de aplicar laadministracion Capitalista fue del 1,80 %.

3.25

3.3

3.35

3.4

3.45

3.5

3.55

3.6

3.65

0 20 40 60 80 100 120

IPC


Comparación del IPC TOTAL de Gcc y Libquantum


Figura 23: IPC global para el conjunto de prueba B.

51


4.5.3. Ancho de banda utilizado

Esta metrica provee una medida del uso de la memoria principal por losprocesos en ejecucion. Al disminuir el ancho de banda utilizado por los nucleosde procesamiento, se deja lugar a que otros dispositivos la accedan mejorandoel rendimiento general del sistema.

Disminuir la tasa de desaciertos en el nivel de memoria cache compartida,implica tener menos accesos a memoria principal (por la jerarquıa de memoriasimulada), lo cual disminuye el ancho de banda utilizado por los conjuntos deprueba. El valor de esta disminucion debe ser cercana al valor logrado en ladisminucion de la tasa de desaciertos global.

0.1

0.15

0.2

0.25

0.3

0.35

0.4

0.45

0 20 40 60 80 100 120

Anch

o D

e B

anda

[%]


Comparación del uso del Ancho de Banda de H264 y Libquantum


Figura 24: Ancho de banda global para el conjunto de prueba A.

0.12

0.14

0.16

0.18

0.2

0.22

0.24

0 20 40 60 80 100 120

Anch

o D

e B

anda

[%]


Comparación del uso del Ancho de Banda de Gcc y Libquantum


Figura 25: Ancho de banda global para el conjunto de prueba B.

52

4.6 Conclusiones 4 AMBIENTE DE SIMULACION

En las figuras 24 y 25 se muestra el ancho de banda de cada obtenido paracada conjunto de prueba, aplicando las polıticas de administracion Capitalistay la desarrollada en esta tesis. Para el conjunto de prueba A, la reduccion deluso del ancho de banda es alrededor del 20 %, mientras que para el conjunto Bes del 12 %.

Parrafo aparte requiere el analisis del conjunto de prueba C. Los benchmarksH.264 y Gcc no tuvieron variacion alguna al aplicar la administracion dinamicapropuesta respecto de la Capitalista. Este resultado es producto de que ambosbenchmarks no tuvieron una cantidad de desaciertos de tipo inter-procesos su-ficiente como para que la heurıstica de administracion propuesta encontrara unbeneficio en el desempeno al variar el espacio asignado a cada proceso. En laejecucion utilizando la polıtica de administracion Capitalista, los desaciertos detipo inter-procesos representaron solo el 2,4 % de los desaciertos en la memoriacache compartida, por lo que, al aplicar la polıtica desarrollada, esta asigno lamisma cantidad de zocalos a cada benchmark y no realizo intercambios de zoca-los, lo cual resulto en una variacion despreciable de las metricas de la tasa dedesaciertos, IPC y Ancho de banda.

4.6. Conclusiones

En este capıtulo, se presento el trabajo relacionado y el estado de arte delas polıticas de administracion dinamica para memorias cache compartidas. Seexpusieron las caracterısticas de la jerarquıa de memoria utilizada para la simu-lacion junto con los motivos de su eleccion y la evaluacion del desempenoobtenido por la polıtica de administracion desarrollada en esta tesis, comparadacon la polıtica Capitalista, a partir de los conjuntos de prueba detallados en laseccion 4.4 de este capıtulo.

Se observa que la polıtica propuesta, presenta una menor tasa de desaciertosen la memoria cache de tipo compartido en forma global para cada conjunto deprueba estudiado. Ciertos procesos ven incrementada su tasa de desaciertos poruna restriccion del espacio otorgado, para que otros procesos hagan un mejor usode ese espacio, logrando aumentar el IPC en forma global. Asimismo, se pudomostrar que se hace un uso mas eficiente del espacio en la memoria cache com-partida, eliminando los desaciertos de tipo inter-procesos y adaptando, a unavelocidad suficiente, el espacio disponible en funcion de la localidad de datos paracada proceso en ejecucion. La heurıstica de administracion dinamica utilizadacumple con su objetivo de administrar el espacio en memoria cache compartidapor cada proceso en la busqueda de mejorar el IPC global.

53

4.6 Conclusiones 4 AMBIENTE DE SIMULACION

Utilizando la polıtica de administracion Capitalista, los conjuntos de pruebano tuvieron una cantidad de desaciertos de tipo inter-procesos que causara unalto solapamiento de los procesos en la memoria cache compartida; esto se debea que se eligio una jerarquıa de memoria con un nivel de recursos superior a losutilizados normalmente en los trabajos relacionados, provocando la disminucionde este tipo de desaciertos. Esto remarca las bondades de las metricas propuestaspara la administracion del espacio que debe ocupar cada proceso (las metricasprovistas por las ecuaciones (9) y (10)), ya que muestran una alta sensibilidad enla prediccion y medicion del desempeno de cada proceso en funcion del espaciootorgado.

Finalmente se analizo el ancho de banda consumido para cada polıtica evalu-ada y se concluye que al realizar una mejor administracion del espacio en lamemoria cache compartida, se reducen sus desaciertos, y por ende los accesos amemoria principal, diminuyendo el consumo del ancho banda en un valor acordea la reduccion lograda en la tasa de desaciertos global para cada conjunto deprueba.

54

5 CONCLUSIONES

Capıtulo 5

5. Conclusiones

En este trabajo de tesis se presento una nueva polıtica para la administracionde las memorias cache de tipo compartidas. Esta se basa en una heurıstica quetiene por objetivo principal mejorar el tiempo de ejecucion de las aplicacionesadministrando el espacio que cada una ocupa en la memoria cache compartidasegun una metrica que evalua esta necesidad cada cierta cantidad de ciclos deejecucion. Esta metrica (definida en la seccion 3.3.3), toma los desaciertos en lamemoria cache compartida producidos por cada proceso en ejecucion, los agrupasegun la clasificacion D3C, y mide la equidad de los recursos asignados hasta esemomento para cada proceso, en funcion de su tasa de desaciertos. Se pretendeotorgar el espacio en memoria cache compartida de la manera mas equitativa,definiendo esta equidad como la normalizacion de los desaciertos de Capacidadproducidos en un ambiente de ejecucion compartido con los desaciertos de Ca-pacidad producidos como si un proceso dado tuviera todo el espacio en memoriacache dedicado a si mismo.

Para el estudio de la polıtica de administracion propuesta, se construyo unambiente para la instrumentacion dinamica de multiples procesos en ejecucionsimultanea, con el objetivo de recolectar las instrucciones ejecutadas por estos,que alimentando al vuelo a un simulador de jerarquıas de memoria, permi-tio evaluar el desempeno de las polıticas de administracion estudiadas.

En el Capıtulo 1 se presentaron las motivaciones de esta tesis ası como unanalisis del estado del arte de las tecnicas y herramientas utilizadas en esta.En el Capıtulo 2 se presento una herramienta, publica y de codigo abierto,que permite instrumentar y controlar multiples procesos en forma simultaneapara poder analizar las instrucciones que estos ejecutan en distintos modulosintercambiables. La misma, utiliza el framework PIN para la instrumentacion yun Controlador de Procesos el cual se encarga de la comunicacion y recoleccionde la informacion al vuelo para ser enviada al modulo de procesamiento utilizado.Dos modulos de procesamiento fueron desarrollados, el primero utilizado parala validacion de la herramienta que consistio en un recolector de trazas, y elsegundo, un modulo simulador de jerarquıas de memoria, el cual se utilizo paraevaluar las polıticas de administracion bajo estudio.

En el Capıtulo 3 se analizo el trabajo relacionado sobre la administracionde memorias cache compartidas tomado como base para la construccion de laheurıstica de administracion propuesta. Se definio la metrica para la evaluacionde la equidad en el rendimiento para multiples procesos en ejecucion simultaneay la heurıstica a ser implementada para llevar a cabo el objetivo de la polıticade administracion propuesta.

55

5 CONCLUSIONES

En el Capıtulo 4, se indicaron las caracterısticas principales del simuladorde jerarquıas de memoria, ası como los aspectos tenidos en cuenta en su imple-mentacion a nivel de programacion y las posibilidades de implementacion sobrehardware real. Luego, se detallo la configuracion elegida para la simulacion ylos motivos de la eleccion de los parametros de los componentes de hardwaresimulados. Se describieron los benchmarks elegidos para la evaluacion, ası comoel motivo de su eleccion como diferentes conjuntos de prueba para la evaluacionde la administracion propuesta comparada con la Capitalista, que es la utilizadacomo referencia en los trabajos relacionados.

Los resultados obtenidos, muestran una mejora en el desempeno global delas aplicaciones ejecutadas, logrado por una mejor distribucion de los recur-sos de la memoria cache de tipo compartido a nivel de procesos al utilizar laadministracion desarrollada en esta tesis.

El desempeno obtenido, se analizo utilizando tres metricas distintas, tasa dedesaciertos, IPC y ancho de banda. Las dos primeras metricas fueron evaluadasen forma individual para cada benchmark, ası como en forma global para cadagrupo de prueba creado. El motivo de utilizar distintas metricas para la evalua-cion recae en que, en la busqueda de mejorar el desempeno de los procesos enejecucion, se ven afectadas tambien otras metricas importantes que deben sertenidas en cuenta segun el objetivo que se tenga en un ambiente de multiplesprocesos en ejecucion.

El analisis de la tasa de desaciertos mostro que se disminuyeron de formaconsiderable los desaciertos de tipo inter-procesos por separacion del espaciootorgado a cada proceso, y a su vez, al administrar este espacio a una velocidadadecuada segun el valor de la localidad de datos de cada uno. La reduccionmaxima de la tasa de desaciertos global fue del 20 % para el conjunto de pruebaA y del 11 % para el conjunto B.

La evaluacion de la metrica del IPC mostro una mejora del IPC global, me-dida como la cantidad de instrucciones ejecutadas por todos los procesos en lamisma cantidad de ciclos de ejecucion. Estas fueron del 2,35 % para el conjun-to de prueba A y del 1,8 % para el conjunto B. Aquı, se vieron los efectos dela eleccion de los parametros de configuracion para el simulador de jerarquıasde memoria cache. Al utilizar una jerarquıa de memoria de tres niveles y conrecursos muy superiores a los utilizados en otros trabajos relacionados sobreeste tema, se obtuvieron valores menores en las mejoras del desempeno en com-paracion con ellos. Sin embargo, esto muestra que las metricas propuestas sonsensibles a pequenas mejoras en el desempeno global y marca que las hipotesistomadas al definirlas fueron correctas.

El ancho de banda utilizado por cada conjunto de prueba evaluado, se ve re-ducido por la mejor administracion del espacio en la memoria cache compartida.El efecto final observado, es una disminucion del ancho de banda utilizado enun valor similar a la reduccion del valor de la tasa de desaciertos global. Estasreducciones fueron del 20 % para el conjunto A y del 12 % para el B.

Finalmente, se concluye que la metrica de la equidad del espacio otorga-do muestra los beneficios ya reportados en [36, 37], de que la busqueda de laequidad en la administracion de los recursos de memoria cache compartida,reporta beneficios al total de los procesos en ejecucion. Tambien muestra unabuena velocidad de adaptacion del espacio otorgado en funcion del valor de la

56

5.1 Trabajo Futuro 5 CONCLUSIONES

localidad de datos para cada proceso.

Como contrapartida, la polıtica de administracion dinamica desarrollada,requiere adicionar mas hardware para su implementacion real. Sin embargo, lamayorıa de estos requisitos adicionales no son de un costo significativo en la fa-bricacion de la memoria cache ni agregan penalidades considerables en el tiempode acceso. El componente mas costoso a desarrollar es la Pila-LRU utilizada enel calculo de las metricas propuestas para la evaluacion del desempeno invidivualde cada proceso en ejecucion. Si bien las implementaciones en el hardware actualutilizan la distancia de pila Pseudo-LRU, las metricas pueden ser aplicadas deigual forma incurriendo en una disminucion de su precision.

5.1. Trabajo Futuro

Como trabajo futuro queda por evaluar la polıtica de administracion dinami-ca en un ambiente de prueba con una mayor cantidad de nucleos (superior a 8),para poder apreciar el comportamiento de la heurıstica desarrollada sobre unamemoria cache compartida sobre-explotada.

Otro aspecto a evaluar es la aplicacion de la heurıstica a nivel de hilos deprocesamiento. Esto puede ser medido en ambientes de multiples hilos de ejecu-cion por nucleo de procesamiento (SMT) o en multiples nucleos con multipleshilos de procesamiento. Esta nueva evaluacion requerira la modificacion de laPintool desarrollada para que pueda detectar los distintos hilos de ejecucionpor proceso. El Controlador de Procesos no sufrira cambios pero si lo haran losmodulos de procesamiento que deberan tambien clasificar la informacion, segunde que hilo y de que proceso sea.

Otro aspecto a evaluar, es el uso del algortimo de pila Pseudo-LRU y suimpacto en el desempeno de las metricas propuestas ya que se disminuye laprecision para la clasificacion de los desaciertos.

57

A PINTOOL DE INSTRUMENTACION

Apendice A

A. Pintool de Instrumentacion

A.1. Detalles de implementacion

La Pintool de instrumentacion, llamada PintoolCAR (Pintool ControladorAuto-Registro) esta basada en la herramienta Pinatrace provista como ejem-plo por el framework PIN. Esta programada en lenguaje C++. La version dePIN utilizada es la 2.7-31933. Esta version tiene como recomendacion utilizar elcompilador GCC [46] version 3.4.6.

Una Pintool esta compuesta por tres (3) secciones bien definidas:

Main: Donde se reciben los parametros de entrada y se inicializan lasvariables a utilizar. Tambien aquı es donde se definen las funciones deinstrumentacion y analisis.

Funciones de Instrumentacion y Analisis: son las encargadas de instru-mentar y obtener la informacion del proceso en ejecucion.

Fini: Esta funcion es llamada al finalizar la instrumentacion del proceso(PIN, al detectar que este termino su ejecucion la llama automaticamente)en la cual se finalizan las variables utilizadas.

La ejecucion para la instrumentacion con PIN requiere de:

Parametros de configuracion.

Una Pintool para instrumentar.

Binario ejecutable a instrumentar.

Los parametros utilizados son dos. El primero, follow execv, le indica a PINque debe instrumentar todos los procesos que sean creados por el binario eje-cutable instrumentado y el segundo, t, indica el directorio donde se encuentrala Pintool. Un ejemplo de la ejecucion se describe a continuacion:

$./pin -follow_execv -t PATH_DIRECTORIO_PINTOOL/Pintool.so -- <comando>

A.2. Modo de uso

En primer lugar, se explicara como instalar la herramienta PIN, luego seindicara como compilar la Pintool desarrollada para la comunicacion con losmodulos y su ejecucion.

1. Descargar la version 2.7.31933 de PIN. Al momento de la redaccion de estatesis se la podıa encontrar en: http://www.pintool.org/downloads.html.

2. Al descomprimir el archivo descargado, se vera el siguiente arbol de direc-torios:

58

A.2 Modo de uso A PINTOOL DE INSTRUMENTACION

pin-2.7.31933 =

doc \

extras \

ia32 \

intel64 \

source \

pin

3. PIN ya esta precompilado y en el directorio source se encuentran distintosejemplos de Pintools disponibles (entre ellas Pinatrace). Para utilizarlas,cada una posee un archivo de tipo Makefile el cual ejecutando el comandomake se procedera a su compilacion. Finalizada esta, la Pintool quedalista para ser utilizada por PIN.

4. Obtener el codigo fuente de la PintoolCAR desarrollada en esta tesis.Ingresarla en directorio source/tools dentro del directorio pin-2.7.31933 ycompilarla con el archivo Makefile que contiene en su interior.

Una vez instaladas las herramientas se puede proceder a la instrumentacionutilizando el ejemplo de ejecucion dado anteriormente. Al ser el Controlador deProcesos el que recibe la informacion de instrumentacion, este debera ser ejecu-tado con anterioridad a PIN. Al iniciarse, el Controlador de Procesos configurasu entorno y envıa un mensaje al usuario indicando cuando es el momento deejecutar el comando para iniciar la instrumentacion con PIN.

La PintoolCAR guarda en un archivo de tipo log, indicando la fecha, horae identificador de cada proceso instrumentado, donde se indica el nombre delbinario ejecutable instrumentado ası como su inicio y fin de instrumentacion. Elarchivo cantidadInstruccionesHastaInstrumentar posee el valor de la cantidadde instrucciones que se ejecutaran sin ser enviadas al Controlador de Procesos.

59

B MODULO RECOLECTOR DE TRAZAS

Apendice B

B. Modulo Recolector de trazas

B.1. Detalles de implementacion

Por simplicidad y comodidad se provee el modulo recolector de trazas juntocon el Controlador de Procesos en un solo binario ejecutable. Este modulo ası co-mo el Controlador de Procesos fueron programados en lenguaje C++. Para sucompilacion se provee de un archivo de tipo Makefile, con el cual, al ejecutar elcomando make se compila el modulo junto con el Controlador de Procesos.

Al utilizar la biblioteca Zlib para realizar la compresion de las trazas, esnecesario proveer el directorio donde se encuentra esta biblioteca. Para ello enel archivo Makefile, se indica el lugar a ingresar este directorio. Finalizada lacompilacion, la aplicacion queda lista para ser utilizada.

B.2. Modo de uso

El generador de trazas puede recibir cuatro parametros, de los cuales dos deellos son opcionales:

-i (–instrucciones): Indica la ubicacion absoluta del archivo de instruc-ciones a crear (Obligatorio).

-c (–cantidad): indica la cantidad de instrucciones (en millones) a obtener.

-h (–help): imprime la ayuda.

Un ejemplo de ejecucion serıa:

./gdt -i instrucciones.z -c 500

El cual indicara que las instrucciones instrumentadas se guardaran en elarchivo instrucciones.z y se instrumentara un total de 500 millones de instruc-ciones.

B.3. Descompresor

Para leer la informacion almacenada en los archivos comprimidos se desa-rrollo una aplicacion capaz de descomprimir por secciones en forma iterativa oen forma completa, las trazas generadas a fin de poder visualizar y estudiar lainformacion de forma mas conveniente, o usar este descompresor para procesaral vuelo las trazas obtenidas.

B.3.1. Modo de uso

Esta aplicacion puede recibir cinco parametros, de los cuales tres de ellosson opcionales:

-z –zfile - path completo y nombre del archivo del archivo comprimido(OBLIGATORIO).

60

B.3 Descompresor B MODULO RECOLECTOR DE TRAZAS

-o –output - path completo y nombre del archivo de salida a crear (OBLI-GATORIO).

-p –paginado - se descomprime de a paginas. Presionando ENTER sedescomprime una nueva pagina.

-l –limpiar - si se descomprime de a paginas, cada nueva pagina sobre-escribe a la anterior en el archivo de salida.

-h –help - imprime estas instrucciones.


./dgdt -z trazas.z -o salida.txt -p -l

El cual indicara que se descomprima el archivo trazas.z en el archivo detexto plano salida.txt, paginando este ultimo, sobre-escribiendo la informacionde este.

61

C SIMULADOR DE JERARQUIAS DE MEMORIA CACHE

Apendice C

C. Simulador de jerarquıas de memoria cache

C.1. Detalles de implementacion

Por simplicidad y comodidad se provee el modulo simulador de jerarquıasde memoria cache junto con el Controlador de Procesos en un solo binario eje-cutable. Este modulo ası como el Controlador de Procesos fueron programadosen lenguaje C++. Para su compilacion se provee de un archivo de tipo Make-file, con el cual, al ejecutar el comando make se compila el modulo junto con elControlador de Procesos.

Dentro del directorio de la herramienta, se encuentra el archivo Defini-ciones.h, en cual se especifican todos los parametros de configuracion de lamisma. Estos parametros, correctamente comentada su finalidad, son los queindican las penalidades, la cantidad de zocalos a crear bajo administraciondinamica, etc. Antes de compilar y ejecutar es necesario revisar este archivoa fin de que el simulador quede configurado como es esperado.

C.2. Modo de uso

El generador de trazas puede recibir cuatro parametros, de los cuales dos deellos son opcionales:

-s (–salida): Indica la ubicacion absoluta del archivo de salida en formatoCSV (Obligatorio).

-p (–pruebas): Se ejecutan solo las pruebas unitarias desarolladas para elsimulador.

-c (–cantidad): indica la cantidad de instrucciones (en millones) a simular.

-h (–help): imprime la ayuda.


./sjmc -s salida.csv

El cual guardara la informacion de la jerarquıa de memoria simulada enarchivo salida.csv. Este formato es de uso por defecto en las hojas de calculo.Se provee este tipo de formato de salida para ası poder analizar la informacionde forma mas simple y efectiva.

62

D MEDIO DIGITAL

Apendice D

D. Medio Digital

Junto con esta tesis, se incluye un CD con el codigo fuente de las herramien-tas desarrolladas y los binarios requeridos para su compilacion. El ındice dedirectorios es el siguiente:

TESIS_CCA

descompresorDeTrazas \

documentacion \

g++-3.4_gcc-3.4 \

generadorDeTrazas \

pin-2.7-31933-gcc.3.4.6-ia32_intel64-linux \

simuladorJerarquiasDeMemoria \

En las secciones a continuacion se indica el contenido mas relevante de cadadirectorio ası como las especificaciones para su uso.

D.1. Descompresor de Trazas

En este directorio se encuentra la aplicacion para descomprimir el archivo detrazas obtenido al ejecutar el modulo generador de trazas. Este cuenta con unarchivo tipo Makefile el cual crea el binario ejecutable del descompresor llamadodgdt (Descompresor Generador De Trazas).

D.2. Documentacion

En este directorio, se encuentra esta tesis, ası como una copia de la licenciapublica general GNU (version 3.0), ambas en formato PDF.

D.3. Compiladores gcc y g++ versiones 3.4.6

En el directorio g++-3.4 gcc-3.4 se encuentran los archivos binarios nece-sarios para instalar los compiladores gcc y g++ en su versin 3.4.6. Estos sonnecesarios para compilar la ambiente de desarrollo PIN, ası como el generadorde trazas y el simulador de jerarquıas de memoria.

Los archivos dentro de este directorio son:

cpp-3.4_3.4.6-6ubuntu5_i386.deb

g++-3.4_3.4.6-6ubuntu5_i386.deb

gcc-3.4_3.4.6-6ubuntu5_i386.deb

gcc-3.4-base_3.4.6-6ubuntu5_i386.deb

install

libstdc++6_4.2.4-1ubuntu4_i386.deb

63

D.4 Generador de Trazas y Simuladorde Jerarquıas de Memoria Cache D MEDIO DIGITAL

libstdc++6-dev_3.4.6-6ubuntu5_i386.deb

Dentro del archivo install se encuentra el comando necesario para instalaren el sistema operativo la version 3.4.6 de los compiladores gcc y g++. Para re-alizar la instalacion se debe poder ser administrador (super usuario) del sistemaoperativo y ejecutar el siguiente comando:

#sudo dpkg -i cpp-3.4 3.4.6-6ubuntu5 i386.deb g++-3.4 3.4.6-6ubuntu5 i386.deb

gcc-3.4 3.4.6-6ubuntu5 i386.deb gcc-3.4-base 3.4.6-6ubuntu5 i386.deb

libstdc++6-dev 3.4.6-6ubuntu5 i386.deb

A continuacion de la ejecucion del comando, se pedira la clave (password)de administrador del sistema operativo y se procedera a la instalacion. Unavez completada se puede comprobar su correcto funcionamiento ejecutando elcomando:

$/usr/bin/gcc-3.4 --version

gcc-3.4 (GCC) 3.4.6 (Ubuntu 3.4.6-6ubuntu5)

Copyright (C) 2006 Free Software Foundation, Inc.

This is free software; see the source for copying conditions. There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$/usr/bin/g++-3.4 --version

g++-3.4 (GCC) 3.4.6 (Ubuntu 3.4.6-6ubuntu5)

Copyright (C) 2006 Free Software Foundation, Inc.

This is free software; see the source for copying conditions. There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Nota: Puede reemplazarse la version de gcc y g++ por defecto del sistemaoperativo por la 3.4.6 eliminando el acceso directo y reemplazandolo por estaversion ejecutando los comandos:

#ln -s gcc-3.4 gcc

#ln -s g++-3.4 g++

D.4. Generador de Trazas y Simuladorde Jerarquıas de Memoria Cache

En cada uno de los directorios donde se encuentran las herramientras de-sarrolladas se cuenta con un archivo de tipo Makefile, el cual al ejecutarlo seprocede a la compilacion de los archivos fuentes que componen a la herramienta.Finalizada la compilacion, se obtendra un archivo ejecutable llamado gdt o sjmcen cada caso.

D.5. Framework PIN version 2.7-31933

En este directorio se encuentra la version de PIN utilizada en esta tesis. PINya esta precompilado y en el directorio source se encuentran distintos ejemplosde Pintools disponibles. Cada una posee un archivo de tipo Makefile, el cualejecutando el comando make se procedera a su compilacion. Finalizada esta,la Pintool queda lista para ser utilizada por PIN. Ademas, en el directoriosource/tools hay un archivo tipo Makefile el cual compila todas las Pintools

64

D.5 Framework PIN version 2.7-31933 D MEDIO DIGITAL

provistas por PIN. En el directorio src/tools, donde residen todas las Pintoolsdisponibles, se encuentra el directorio con la PintoolCAR, desarrollada en estatesis.

65

REFERENCIAS REFERENCIAS

Referencias

[1] D. Burger and S. Keckler, “Exploring the design space of future CMPs,”Proceedings 2001 International Conference on Parallel Architectures andCompilation Techniques, pp. 199–210, 2001.

[2] J. L. Hennessy and D. A. Patterson, Computer Architecture: A QuantitativeApproach, vol. 3rd. Morgan Kaufmann, 2006.

[3] J. Chang, M. Huang, J. Shoemaker, J. Benoit, S.-l. Chen, W. Chen, S. Chiu,R. Ganesan, G. Leong, V. Lukka, S. Rusu, and D. Srivastava, “The 65-nm16-MB Shared On-Die L3 Cache for the Dual-Core Intel Xeon Processor7100 Series,” 2007.

[4] S. Tam, S. Rusu, J. Chang, S. Vora, B. Cherkauer, and D. Ayers, “A 65nm95W Dual-Core Multi-Threaded Xeon Processor with L3 Cache,” pp. 15–18, 2006.

[5] D. Patterson, T. Anderson, N. Cardwell, R. Fromm, K. Keeton,C. Kozyrakis, R. Thomas, and K. Yelick, “A case for intelligent RAM,”IEEE Micro, vol. 17, no. 2, pp. 34–44, 1997.

[6] J. L. Hamkalo, “Modelizacion y Simulacion de jerarquıas de memoria,”2005.

[7] A. J. Hill, Mark adn Smith, “Evaluation Associativity in CPU Caches,”IEEE, no. vol 38 No 12, 1989.

[8] J. L. Hamkalo and B. Cernuschi-Frıas, “A Taxonomy for Cache MemoryMisses,” Proc. of the 11th Symposium on Computer Architecture and HighPerformance Computing, pp. 67–73, 1999.

[9] “Manual de procesadores intel.” http://www.intel.com/Assets/PDF

/manual/253668.pdf.

[10] L. Peng, J. Peir, T. Prakash, C. Staelin, Y. Chen, and D. Koppel-man, “Memory hierarchy performance measurement of commercial dual-core desktop processors,” Journal of Systems Architecture, vol. 54, no. 8,pp. 816–828, 2008.

[11] “Manual del procesador ultrasparc iv+.” http://www.met.reading.ac.uk

/∼ swsellis/tech/solaris/performance/doc/text/USIVplus v1.0.pdf.

[12] R. V. D. Pas and H. Performance, “Memory Hierarchy in Cache- BasedSystems,” 2002.

[13] G. Hamerly and B. Calder, “Discovering And Exploiting Program Phases,”Ieee Micro, pp. 84–93, 2003.

[14] “The power4 processor introduction and tuning guide.”www.redbooks.ibm.com/redbooks/pdfs/sg247041.pdf.

[15] L. R. Hsu, A. Arbor, and S. Reinhardt, “Communist , Utilitarian , andCapitalist Cache Policies on CMPs : Caches as a Shared Resource,” 2006.

66


[16] “Simplescalar llc.” http://www.simplescalar.com.

[17] A. Jaleel, R. S. Cohn, C.-k. Luk, and B. Jacob, “CMP$im : A Pin-BasedOn-The-Fly Multi-Core Cache Simulator,”

[18] H. Wan, X. Gao, and Z. Wang, “Cache Simulator based on GPU Acceler-ation,” Proceedings of the Second International ICST Conference on Sim-ulation Tools and Techniques, 2009.

[19] “Valgrind.” http://www.valgrind.org.

[20] C.-k. Luk, R. Cohn, R. Muth, H. Patil, A. Klauser, S. Wallace, V. Janapa,and G. Lowney, “Pin : Building Customized Program Analysis Tools,” 2005.

[21] C. A. Carballal, J. L. Hamkalo, and B. Cernuschi-Frıas, “A Modular Work-flow to Dynamically Instrument and Treat Information in Multi-ProcessEnvironments,” no. ISSN 1850-2776, p. 14, 2010.

[22] A. J. Vega, “Un Ambiente para la Evaluacion de Arquitecturas de Memoriaen Esquemas Multihilo Simultaneo,” 2007.

[23] N. Nethercote and J. Seward, “Valgrind : A Framework for HeavyweightDynamic Binary Instrumentation,” Noviembre 2007.

[24] “Spec cpu2006.” http://www.spec.org/cpu2006/.

[25] “Zlib.” http://www.zlib.net/.

[26] J. L. Hamkalo and B. Cernuschi-Frıas, “Theoretical Analysis of CacheStatistics for the Simple Loop Model,” International Journal of Computersand Applications, vol. 21, pp. 13–18, 1999.

[27] P. Sommerlad and E. Graf, “CUTE : C ++ Unit Testing Easier,” 2007.

[28] “Eclipse cdt.” http://www.eclipse.org/cdt/.

[29] C.-j. Wu and M. Martonosi, “A Comparison of Capacity ManagementSchemes for Shared CMP Caches,”

[30] G. E. Suh, S. Devadas, and L. Rudolph, “Analytical Cache Models withApplication to Cache Partitioning,” 2001.

[31] G. E. Suh, L. Rudolph, and S. Devadas, “Dynamic Cache Partitioning forSimultaneous Multithreading Systems,” 2001.

[32] G. E. Suh, S. Devadas, and L. Rudolph, “Analytical cache models withapplications to cache partitioning,” Proceedings of the 15th internationalconference on Supercomputing - ICS ’01, no. Junio, pp. 1–12, 2001.

[33] G. E. Suh, L. Rudolph, and S. Devadas, “Dynamic Partitioning of SharedCache Memory,” The Journal of Supercomputing, vol. 28, no. 1, pp. 7–26,2004.

[34] M. Moreto, F. J. Cazorla, A. Ramirez, and M. Valero, “MLP-Aware Dy-namic Cache Partitioning,” 2007.

67


[35] M. Moreto, F. J. Cazorla, A. Ramirez, and M. Valero, “Explaining DynamicCache Partitioning Speed Ups,” Architecture, 2007.

[36] S. Kim, D. Chandra, and Y. Solihin, “Fair Cache Sharing and Partitioningin a Chip Multiprocessor Architecture,” 2004.

[37] X. Zhou, W. Chen, and W. Zheng, “Cache Sharing Management for Perfor-mance Fairness in Chip Multiprocessors,” 2009 18th International Confer-ence on Parallel Architectures and Compilation Techniques, pp. 384–393,Sept. 2009.

[38] J. Lin, Q. Lu, X. Ding, Z. Zhang, X. Zhang, and P. Sadayappan, “EnablingSoftware Management for Multicore Caches with a Lightweight HardwareSupport,” 2009.

[39] J. Gecsei, D. R. Slutz, and I. L. Traiger, “Evaluation techniques for storagehierarchies,” IBM Systems Journal, vol. 9, no. 2, pp. 78–117, 1970.

[40] H. Al-Zoubi, A. Milenkovic, and M. Milenkovic, “Performance evaluationof cache replacement policies for the SPEC CPU2000 benchmark suite,”Proceedings of the 42nd annual Southeast regional conference on - ACM-SE 42, p. 267, 2004.

[41] D. Chiou and S. Devadas, “Dynamic Cache Partitioning via Columniza-tion,” 1999.

[42] H. Ghasemzadeh, S. Mazrouee, M. R. Kakoee, and D. Branch, “ModifiedPseudo LRU Replacement Algorithm,” 2006.

[43] G. Keramidas, P. Petoumenos, and S. Kaxiras, “Cache Replacement Basedon Reuse-Distance Prediction,” pp. 245–250, 2007.

[44] “Estructura de un qubit en libquantuml.”http://www.libquantum.de/api/1.1/Quantum-registers.html.

[45] “H.264/avc software coordination.” http://iphome.hhi.de/suehring/tml/index.htm.

[46] “Gcc.” http://gcc.gnu.org/.

68

estudio, an alisis y modelado de memorias cach e...

Documents