Transcript tema 3

3. Coherencia de los datos en
multiprocesadores SMP
- Introducción
- Protocolos de tipo snoopy
- Protocolos de invalidación
- Protocolos de actualización
- Atomicidad
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
1
Introducción
 La memoria de un computador está
organizada jerárquicamente:
Reg.
MC1
MC2...
MP
Disco
+ capacidad
+ velocidad
 Los accesos a memoria no son aleatorios:
t → @A
t → @A
UPV-EHU / ATC
t + ∆t →@A
t + 1 → @A+1
Arquitecturas Paralelas 12-13
2
Introducción
Reg.
MC1
MC2...
palabra
MP
Disco
bloque
 Cada nivel de memoria es un subconjunto del
anterior.
Objetivo: dado que no caben todos los datos,
traeremos a la cache aquellos datos que, con
mayor probabilidad, se vayan a utilizar.
La unidad de transferencia es el bloque (line):
N palabras de direcciones contiguas.
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
3
Introducción
Reg.
MC1
MC2...
MP
Disco
 Se trabaja con copias de los datos. ¿Cómo se
mantienen iguales (coherentes) esas copias?
Política de escritura.
write-through: los cambios se hacen en todas las
copias, genera mucho tráfico en el bus.
write-back: los cambios se hacen solo en niveles
inferiores; las copias se actualizan en memoria
principal cuando hay que reemplazar los datos.
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
4
Introducción
 En multiprocesadores SMP, se utilizan memoria
compartida y variables compartidas para comunicar
procesos. Por lo tanto, el número de copias de los
bloques de datos puede ser mayor (P+1) y las copias
no dependen de una única unidad de control.
UPV-EHU / ATC
Reg.
MC1
MC2...
Reg.
MC1
MC2...
Reg.
MC1
MC2...
Arquitecturas Paralelas 12-13
MP
Disco
5
Introducción
 Aparecen copias de un bloque de datos:
- porque se comparten variables (shared)
- porque están en el mismo bloque, aunque no
se compartan los datos (falsa compartición)
bloque de datos
X
Y
variables del procesador P1
Z
T
variables del procesador P2
 ¿Cómo se mantendrán todas esas copias
coherentes cuando cambia una de ellas?
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
6
Introducción
 El
sistema de memoria tiene que ser
coherente: todos los procesos tienen que
utilizar la misma información y actualizada.
 Se dice que un sistema es coherente si:
- al leer una variable, se obtiene el último valor
escrito en esa variable (si ha transcurrido
suficiente tiempo desde la escritura).
- todas las escrituras sobre una variable se “ven” en
el mismo orden en todos los procesadores.
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
7
Introducción
 Hay dos estrategias para mantener coherentes
los sistemas de memoria compartida:
Sistemas SMP: pocos procesadores, memoria
centralizada, bus
→ protocolos de tipo snoopy
Sistemas DSM: muchos procesadores,
memoria distribuida, red
→ directorios de coherencia
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
8
Protocolos snoopy
 Para la comunicación entre los procesadores de un
sistema SMP y su memoria se utiliza un bus. El
bus es una red centralizada, y, por lo tanto,
todas las transferencias de datos son “públicas”.
¿Cómo se puede saber que una variable que está
en nuestra cache se necesita o cambia en otro
procesador?
>> Espiando el bus para saber qué hacen los
demás y enviando señales de control
especiales a todos los procesadores por
medio del bus.
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
9
Protocolos snoopy
 ¿Qué hay que hacer con una copia de un bloque si
cambia en otro procesador?
wr A,#3
cache
A=4

A=3
A=4
- Como la información ya
no se puede utilizar las
copias se invalidan.
A=4

INV A
protocolos de invalidación
A=4
UPV-EHU / ATC
mem. principal
Arquitecturas Paralelas 12-13
10
Protocolos snoopy
 ¿Qué hay que hacer con una copia de un
bloque si cambia en otro procesador?
wr A,#3
cache
A=3
A=4
A=3
A=4
- La información de las
copias se actualiza con
el nuevo valor.
A=4
A=3
BC A, 3
protocolos de actualización
A=4
UPV-EHU / ATC
mem. principal
Arquitecturas Paralelas 12-13
11
Protocolos snoopy

Para gestionar las copias de los bloques de datos, se
añade información de control en el directorio de la cache.
Se utilizan esos bits de control para definir los estados
de los bloques. Se utilizan los 5 estados siguientes :
I
E
M
S
O
UPV-EHU / ATC
inválido
exclusivo: una sóla copia y coherente con MP
modificado: una sóla copia y no coherente con MP
compartido: varias copias, todas coherentes
propietario: varias copias (una O, las otras S)
no coherentes con MP
Arquitecturas Paralelas 12-13
12
Protocolos snoopy
 Para definir esos 5 estados hacen falta 3 bits en
el directorio de la cache:
valid dirty shared
UPV-EHU / ATC
0
-
-
I
1
1
0
0
0
1
E
S
1
1
1
1
0
1
M
O
Arquitecturas Paralelas 12-13
13
Protocolos snoopy
 Para gestionar los estados de los bloques de
datos y generar las señales de control el snoopy
tiene que espiar dos fuentes de información:
1. las acciones del procesador local
2. las acciones correspondientes al resto de
procesadores que aparecen en el bus
P
C
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
snoopy
14
Protocolos snoopy
1. Acciones del procesador local:
PR @
El procesador lee una palabra. Si no está en
cache habrá que pedir el bloque → BR @
PW @,dat
El procesador escribe una palabra.
Hay que invalidar o actualizar el resto de las
copias del sistema: INV @ o BC @,dat.
Además, si es fallo, habrá que pedir el
bloque
(BR + INV/BC).
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
15
Protocolos snoopy
2. Acciones de otros procesadores:
BR @
Otro procesador ha pedido un bloque. Si está
en la cache local, actualizar el estado…
INV @
Un procesador ha generado la señal para invalidar
un bloque concreto. Si está en la cache, hay que
invalidar el bloque.
BC @,dat
Un procesador ha generado la señal para
actualizar una palabra. Si está en la cache…
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
16
Protocolos snoopy
3. Otras señales de control:
BW Escritura de un bloque en memoria principal (WB)
BW* Escritura de una palabra en memoria principal (WT)
 En función de los estados, política de escritura,
estrategia para gestión de copias, etc. Se
obtienen distintos protocolos de tipo snoopy.
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
17
Protocolos de invalidación (1)
Protocolo MSI (Silicon Graphics)
PR - PW
PR
PW
BR
M
INV
acierto.
fallo
BR
I, -
S
BR
M
PW
BR,INV
(INV)
S
S
M INV
S
M
M
M
S
I
BW
I
(BW)
PR -BR
INV
(BW)
S
BW
INV
PR
PW
(BR)
(BR,INV)
I
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
18
Protocolos de invalidación (1)
 Ojo: el protocolo de coherencia tiene que
generar el menor tráfico posible.
M:
MC1 → MP → MC2
MC1 → MP, MC2
 En algunos casos hay más de una opción para
traer un bloque.
S:
UPV-EHU / ATC
MCi, MCj.... / MP → MCk
Arquitecturas Paralelas 12-13
19
Protocolo de invalidación (2)
Protocolo MESI (Illinois): estado E / línea de control sh
PR - PW
acierto
fallo
PR
I, -
nsh:
sh:
E
S BR
PW
M
BR
BR,INV
M
S
I
S
S
M
S
I
UPV-EHU / ATC
M
INV
S
BW
I
Arquitecturas Paralelas 12-13
PR
(BR,INV)
BW
BR
S
INV
PR nsh
(BR)
(BW)
(INV)
E
PW
INV
PW
PW
E
M
BR
(BW)
E
M
M
INV
PR -BR
INV
PR sh
(BR)
I
20
Protocolo de invalidación (3)
Protocolo MOSI (Berkeley): estado O
PW
(INV)
PR - PW
acierto
fallo
PR
I, -
S
PW
BR
M
BR
M
INV
BR,INV
BR
PR -BR
O
INV
PW
(BW)
(INV)
S
S
M
M
M
M
O
O
UPV-EHU / ATC
M
INV
INV
S
I
O
I
O
I
Arquitecturas Paralelas 12-13
INV
S
(BW)
BW
PW
(BR,INV)
BW
PR -BR
INV
PR
(BR)
I
21
Protocolos de actualización (1)
Protocolo MSE(I) (Firefly): línea de control sh
fallo
PR
-
acierto
E
nsh:
sh:
E
S BR
E
S
S
M
M
PW
nsh:
sh:
sh:
BC
(BR)
M BR
S BR,BC
M
nsh:
BR
PW nsh
E
S BC
M
PR - PW
M
BR (BW)
PW PW nsh
S
(BC)
S
PR
S
S
E
S
BW
S
S
PR -BR-BC
PW sh
BR
BW
PR nsh
(BR)
(BC)
PR sh
(BR)
PW sh
(BR,BC)
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
22
Protocolos de actualización (2)
Protocolo MOES(I) (Dragon): sh línea de control
acierto
fallo
PR
nsh:
E
E
S
S
M
M
O
UPV-EHU / ATC
E
S BR
-
sh:
O
PW
nsh:
sh:
sh:
M O BC
M
nsh:
sh:
BC
M BR
O BR,BC
M
nsh:
BR
M O BC
S
S
S
S
O
S
O
S
Arquitecturas Paralelas 12-13
23
Resumen
 Resumen
El snoopy es hardware de control específico de las caches
y se utiliza en sistemas SMP para mantener la coherencia
de los datos. Espía las operaciones del procesador local y
las del resto de procesadores (gracias al bus).
Actualiza los estados de los bloques de datos en la cache,
y genera señales de control especiales para avisar al
resto de los snoopy-s.
Cuando cambia el contenido de una copia (una escritura),
hay dos opciones: invalidar el resto de las copias, o
actualizarlas.
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
24
Resumen
 Resumen
Se pueden definir varios protocolos de coherencia en
función de los estados, políticas de escritura etc. que se
utilizan.
Hay que intentar minimizar el tráfico que se genera de
datos y de control.
Importante: cuando un bloque pasa de estado M/O a
estado E/S hay que actualizar la memoria principal (y,
por supuesto, cuando se produce un remplazo de un
bloque modificado).
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
25
Controlador de coherencia
 Controlador de coherencia
Para mantener la coherencia el hardware
tiene que controlar tanto las acciones del
procesador como del “bus”.
Las peticiones para trabajar con la cache
pueden venir simultáneamente del
procesador local y del “bus”.
P
C
snoopy
El snoopy es un algoritmo distribuido y por definición, no
atómico; por tanto, pueden aparecer varios problemas.
Veamos las características físicas de un determinado
controlador de coherencia, para entender cómo se resuelven
algunos problemas.
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
26
Controlador de coherencia
MC
tags +
state
Bus side
controller
P
Cache data RAM
snoopy
contr
addr
data
tags +
state
proc.
Processor
side
controller
compar to
controller
tag
Write-back buffer
compar
to
controller
state
Cmd
Addr
Data buffer
Addr
system bus
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
Cmd
Replicar el
directorio de la
cache, uno para el
procesador y el otro
para las operaciónes
del “bus”.
Un bloque de datos
puede estar también
en el búfer de
escritura: hay que
replicar el hardware de
búsqueda.
27
Controlador de coherencia
MC
tags +
state
Bus side
controller
P
Cache data RAM
snoopy
contr
addr
data
tags +
state
proc.
Processor
side
controller
-
compar to
controller
tag
Write-back buffer
compar
to
controller
state
Cmd
Addr
¿Cuánto tiempo hay
que esperar a la
respuesta de los
snoopys?
Data buffer
Addr
Cmd
tiempo fijo (max.)
tiempo variable
(el necesario)
Más líneas de control
en el bus:
sh, dirty, inh...
system bus
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
28
Controlador de coherencia
 El problema principal es la falta de atomicidad:
se pueden mezclar acciones de distintos
procesadores sobre el mismo bloque de datos.
P.e., dos procesadores, a la vez, solicitan el mismo
bloque de datos. Si en ese momento no hay
ninguna copia en el sistema (sh = 0), ambos
cargarán el bloque en estado E!
O, dos procesadores escriben a la vez en su cache
en un bloque que está en estado S, por lo que se
anulan mutuamente sus copias!
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
29
Controlador de coherencia
 Una simplificación: la utilización del bus es
atómica. Para ello, dos señales de control:
BRQ (bus request): quiero utilizar el bus.
BGR (bus grant): el bus es para ti.
 A pesar de todo, la atomicidad no está
garantizada, y por lo tanto, pueden ocurrir
carreras (races):
llegar, siguiendo un algoritmo, a un estado
incorrecto, debido a que el algoritmo no se ha
ejecutado de manera atómica.
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
30
Carreras
 Solución:
Además de la atomicidad de las operaciones
del bus (BRQ, BGR), añadir estados
transitorios al protocolo de coherencia.
Los estados transitorios no se introducen en el
directorio (a nivel de bloque) sino que son
estados del controlador.
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
31
Controlador de coherencia
MC
tags +
state
Bus side
controller
P
Cache data RAM
snoopy
addr
data
tags +
state
proc.
contr
Processor
side
controller
compar to
controller
tag
Write-back buffer
compar
to
controller
state
Cmd
Addr
Data buffer
Addr
Cmd
system bus
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
32
Carreras
PW/PR
Protocolo MESI
M
BGR (BR,INV)
BR (BW)
INV (BW)
BGR (INV)
 IM / SM / ISE
IM
INV
SM
PW
 BRQ / BGR
E
BR
PW (BRQ)
S
BGR (BR) sh
PR
BGR (BR) nsh
INV
PW (BRQ)
ISE
PR/BR
INV
PR (BRQ)
I
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
33
Carreras
 Otros problemas que suelen aparecer en
algoritmos distribuidos:
Deadlock: el sistema se bloquea para siempre no
puede ni continuar ni retroceder.
Livelock: el sistema no esta bloqueado pero repite
lo mismo una y otra vez, y no puede continuar.
Starvation: ciertos snoopy-s no consiguen nunca
llevar a cabo las operaciones correspondientes
porque siempre se adelantan los demás.
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
34
Jerarquía de buses
 En sistemas SMP, el bus se utiliza para la
comunicación entre memoria y procesos.
Que el acceso a memoria sea centralizado supone
muchos problemas porque el bus se satura fácil →
el número de procesadores es limitado.
La solución general es dividir la memoria y así se
obtienen sistemas DSM, donde se utilizan redes de
comunicación.
En esos sistemas no se utilizan los snoopy-s.
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
35
Jerarquía de buses
 Como adelanto, veamos un caso en el que la red
de comunicaciones es una jerarquía de buses y
se puede utilizar el snoopy.
SMP
P
snoopy local
C
B1
MP
K
K
MP
B2
Hardware para coherencia
global
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
36
Jerarquía de buses
 Los controladores de coherencia son un estilo
de “directorios” que almacenan información
sobre los bloques. Se dividen en dos partes:
KL:
información de bloques locales que se
han llevado a caches remotas (estados)
KR: información de bloques remotos traídos
a caches locales (estados/datos)
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
37
Jerarquía de buses
MC
MC
S
S
rd, fallo
MC
MC
M S
ES
BR @
MP
B1
@
KL
B1
KR
MP
KL
M S
KR
E S
M S
E S
B2
UPV-EHU / ATC
Arquitecturas Paralelas 12-13
38
Jerarquía de buses
wr
MC
MC
MC
S M
S I
S I
MC
S I
INV @
INV @
MP
B1
KL
KR
UPV-EHU / ATC
MP
MP
KL
S M
B2
MC
MC
KR
S I
INV @
KL
KR
S M
INV @
Arquitecturas Paralelas 12-13
39