El protocolo de coherencia estándar SCI en la máquina NUMA-Q de Sequent

Como segundo ejemplo de protocolos de coherencia, vamos a analizar el protocolo que se define en el estándar SCI (Scalable Coherent Interface) de IEEE. La información de coherencia se distribuye entre las caches formando listas doblemente ligadas, y se ha utilizado, por ejemplo, en la máquina NUMA-Q (Sequent), un multiprocesador pensado para desarrollar aplicaciones comerciales (o también en el Exemplar de Convex, en el ámbito del cálculo científico).

NUMA-Q es un multiprocesador "pequeño", con 32 procesadores. Los nodos de la red consisten en una tarjeta con 4 procesadores —4 Pentium pro, bus, snoopy—. Para conectar los 8 nodos se utiliza una red simple: un anillo (con enlaces de 1 GB/s).

Los nodos (las tarjetas de 4 procesadores) se conectan a la red (al anillo) mediante un interfaz o gestor de comunicación específico, denominado IQ-

link. Además de encaminar los paquetes, este dispositivo también gestiona la

coherencia, para lo que utiliza una "cache" de 32 MB, denominada remote

access cache, en la que se guardan los bloques de datos que se han traído

4P 4P 4P 4P 4P 4P P MC M _E/S PCI E/S IQ link P MC P MC P MC 4P 4P

desde otros nodos, es decir, los que se han copiado en alguna de las caches locales (similar a la solución que hemos analizamos en el caso de una jerarquía de buses). La cache remota y las caches internas del nodo cumplen el "principio de inclusión"; por tanto, si se reemplaza un bloque en la cache remota, se debe invalidar en las caches internas. Del mismo modo, si se modifica un bloque en una cache interna, hay que actualizar el estado de ese bloque en la cache remota. Los bloques son de 64 bytes.

La coherencia de los datos se mantiene de manera jerárquica: dentro de cada nodo mediante los snoopy locales (un protocolo MOESI de invalidación), y entre los nodos mediante el directorio distribuido por los IQ, que implementa el protocolo SCI, con listas distribuidas en las caches. Analicemos, aunque sea por encima, algunos aspectos del protocolo38_.

7.3.2.1 SCI: estados y operaciones

El estado correspondiente a un determinado bloque va a estar repartido en MP y en las caches. En la parte de directorio que está junto a MP, se indica la dirección de la primera copia y el estado del bloque. Un bloque puede estar en alguno de estos tres estados:

• Home: no existe ninguna copia en ninguna cache (la lista está vacía). • Fresh: existen copias, y todas son iguales y coherentes con la

información de memoria principal.

• Gone: la información de MP no está actualizada; el bloque está modificado en las caches.

En esta parte del directorio no se utilizan los estados de tipo busy.

También en las caches se guarda información sobre los bloques (se utilizan 7 bits, y el estándar define 29 estados normales y una gran cantidad de estados transitorios, de los que sólo vamos a ver unos pocos). Los estados permanentes de un bloque están divididos en dos partes:

• La posición que ocupa el bloque en la lista de copias (dónde está el bloque). Hay cuatro posibilidades: Only (copia única), Head (primera copia), Mid (copia intermedia), y Tail (última copia).

• El estado: Dirty (M), Fresh (S), Valid (S’), Exclusive (E), Stale...

38 El estándar SCI admite cualquier tipo de topología: cadena, anillo, redes jerárquicas, redes multietapa (Omega), etc. Admite hasta 64 k procesadores; las direcciones son de 64 bits: 16 bits para identificar el procesador, y los restantes 48 bits para indicar la dirección de memoria.

Por tanto, el estado de un bloque puede ser: head-dirty, tail-valid... En la siguiente tabla se presentan los estados más utilizados:

Memoria principal

Memorias cache

primero medio último

Home - - - no hay copias

Fresh Only-Fresh - - una sola copia, coherente (E)

Fresh Head-Fresh - Tail-Valid dos copias, coherentes (S) Fresh Head-Fresh Mid-Valid Tail-Valid muchas copias, coherentes

Gone Only-Dirty - - una sola copia, modificada (M)

Gone Head-Dirty - Tail-Valid dos copias, modificadas (O/S’) Gone Head-Dirty Mid-Valid Tail-Valid muchas copias, modificadas (O/S’) Gone Head-Exclusive - Tail-Stale dos copias (ping-pong)39 Gone Head-Stale - Tail-Exclusive dos copias (ping-pong)

Como sabemos, para mantener la coherencia de los bloques hay que realizar muchas operaciones de comunicación. El estándar de coherencia SCI define tres funciones de coherencia para realizar todas esas funciones:

• Insertion o List Construction: para añadir una copia a la lista. • Deletion o Roll-out: para eliminar una copia de la lista.

• Reduction o Purge: para invalidar el resto de las copias de la lista. En cuanto a la comunicación, todas las operaciones son del tipo

pregunta/respuesta. Además, no utiliza mensajes NACK para asegurar la

ejecución atómica de las operaciones, sino búferes (hay alguna excepción). Aplicando el estándar SCI se pueden definir diferentes protocolos:

minimal (no admite copias), typical, full... Analicemos, mediante unos pocos

ejemplos, cómo funciona el protocolo en los tres casos habituales: lecturas, escrituras y reemplazos.

39 La pareja de estados Exclusive / Stale se utiliza para dar una respuesta adecuada a un caso típico de compartición de datos, en el que el bloque sólo se comparte entre dos procesadores. Cuando uno escribe, la copia del otro pasa a estado Stale (vieja) pero no se borran los enlaces. De esa manera, cuando el segundo tiene que volver a usar el bloque, ya sabe dónde tiene que ir a buscarlo, sin necesidad de tener que consultar el directorio.

7.3.2.2 Lecturas (fallo)

Como en los ejemplos anteriores, L (local) es el nodo que ejecuta la operación, H (home) es el nodo que tiene la variable (bloque) en memoria, y R (remote) es el que tiene la primera copia del bloque. Se quiere realizar una lectura en L, pero la variable (el bloque) no está en la cache, por lo que se debe conseguir el bloque de datos que contiene la variable, y colocarlo en la primera posición de la lista de copias, para lo que hay que ejecutar la función

List Construction:

1. Se reserva sitio en la cache para el bloque, y se pone en estado busy. 2. Se envía una petición a H. Cuando llega la petición, el estado del

bloque en el directorio en H puede ser uno de los siguientes:

• Home → No existen copias del bloque en las caches. Ésta será, por tanto, la primera copia. Se cambia el estado a Fresh, y se modifica el puntero para que apunte a la nueva copia (@L). Por último, se envía el bloque de MP (2b). Cuando llega a L, el bloque se carga en la cache en estado Only-Fresh. Dado que no hay más copias, no es necesario guardar punteros.

• Fresh → Existen varias copias del bloque en las caches de los procesadores, unidas en una lista, y hay que situar la nueva copia como primera copia de la lista.

Para ello, se modifica el puntero (2a) para que apunte a la nueva copia, y se envía el bloque de datos (2b) (la copia de MP es

Fresh = coherente) junto con la dirección del anterior cabeza de

lista (@R), ya que L tendrá que comunicarse con él para actualizar los enlaces de la lista.

L H 1b. LC (Rd A) 2b. Bloque Dir (MC) I → busy → O-F | *-* Dir (MP) H | * → F | @L 2a 1a 3

Cuando la respuesta de H llega a L, se carga el bloque en la cache, se mantiene en estado busy (será otro código de busy), y se inicia la segunda suboperación: adecuar el comienzo de la lista. Por tanto, se enviará un mensaje al antiguo cabeza de lista, R, para indicarle quién es ahora la nueva cabeza (new head, 3). Cuando llegue el mensaje a R, se modificará el estado del bloque y los enlaces:

Only-Fresh | * - * → Tail-Valid | @L - * o

Head-Fresh | * - @R2 → Mid-Valid | @L - @R2

Para terminar la operación, R enviará un mensaje de ACK a L (4), La operación se da por terminada al recibir el mensaje y cambiar el estado del bloque a Head-Fresh | * - @R.

• Gone → La copia adecuada del bloque de datos no es la de MP, sino la que está en la cache en la cabecera de la lista. El proceso es el mismo que el anterior, salvo la obtención del bloque, que debe provenir de R. Por tanto, cuando se actualice el estado del bloque y el enlace en la antigua cabeza de lista, se enviará a L, junto con el mensaje ACK, el bloque de datos (4b). El estado del bloque en la cache de L será finalmente Head-Dirty (el bloque está modificado).

7.3.2.3 Escrituras

En el protocolo SCI, únicamente el cabeza de la lista de copias puede modificar el bloque. Además, como es un protocolo de invalidación, habrá que invalidar todas las copias, y quedará como única copia.

R L H 1b. LC (Rd A) 2b. Bloque + @R Dir (MC) I → busy → H-F | *-@R Dir (MP) F | @R → F | @L 2a 1a 3. New Head (@L) Dir (MC) O-F | *-* → T-V | @L-* H-F | *-@R2 → M-V | @L-@R2 4b. ACK 4a 5

Tenemos que distinguir estos casos:

1. (acierto / cabeza). La escritura es en la copia que está en la cabeza de la lista. Se escribe y se invalida el resto de copias (INV).

→ Purge

2. (fallo). El bloque sobre el que se quiere escribir no está en la cache. Hay que conseguir el bloque y colocarlo como cabeza de la lista de copias (List Construction); luego, siendo cabeza, se deben invalidar el resto de las copias. Es decir, "wr-fallo" = "rd-fallo + wr-acierto".

→ List Construction + Purge

3. (acierto / intermedio). El bloque que se quiere modificar se encuentra en una posición intermedia de la lista. Dado que sólo puede escribir la cabeza de la lista, hay que hacer lo siguiente: (a) sacar la copia de la lista de copias (Roll-out), y (b) efectuar las operaciones del caso 2 (fallo).

→ Roll-out + List Construction + Purge

Analicemos, con un poco más de detalle, el primer caso: la escritura sobre la copia de la cabeza de la lista. Para mantener la coherencia, lo único que hay que hacer es invalidar las restantes copias, para lo que se ejecuta la función de coherencia Purge. Según el estado del bloque, el procedimiento es el siguiente (cuatro posibilidades):

1. El estado de la copia de la cabeza es Only-Fresh, es decir, es la única