Traducción de Fernando Berzal
Este artículo presenta una arquitectura de computador paralela denominada PiSMA (Parallel vIrtually Shared Memory Architecture [arquitectura paralela de memoria compartida virtual), planteada en [5, 6]. La arquitectura PiSMA combina las ventajas de los dos modelos de multiprocesador ya mencionados, dando como resultado una arquitectura paralela eficiente. La simplicidad del hardware subyacente permite la escalabilidad de PiSMA utilizando las nuevas generaciones de microprocesadores, sin necesidad de rediseñar el sistema entero. PiSMA puede utilizarse con o sin una red de comunicaciones global dependiendo del tipo de aplicaciones para las que se use, como se describe en [9]. En las siguientes secciones se presentan una descripción detallada de la arquitectura PiSMA, de su modelo de programación y de sus mecanismos de gestión de memoria virtual y paso de mensajes.
Esta estructura permite a cada procesador comunicarse directamente (a través de una memoria común) con hasta ocho procesadores vecinos como se refleja en la figura 2.
El cluster procesador-memoria consiste en dos tarjetas, a saber, la tarjeta del procesador y la tarjeta de memoria. La tarjeta del procesador tiene dos versiones que implementan la connectividad deseada y permiten una fácil expansión. La tarjeta de memoria contiene cuatro módulos de la memoria. Conectando los conectores superior e inferior y el conector izquierdo con el derecho se forma la configuración más pequeña posible (cuatro procesadores y cuatro memorias). La implementación física de la arquitectura se describe detalladamente en [5]. PiSMA es fácilmente escalable y configuraciones más grandes pueden construirse fácilmente conectando repetidamente bloques como el mostrado en la figura 3.
Un aspecto muy importante de la arquitectura básica de PiSMA es que no existe red alguna para la comunicación entre procesadores. En su lugar, los módulos de memoria se utilizan como medio de comunicación, con mensajes que son transferidos a sus destinos mediante copias consecutivas de memoria a memoria. Esta operación de copia es realizada por los procesadores comunes a cada par de memorias. En [9] se mostró que esta estrategia funciona bien para una amplia gama de aplicaciones paralelas y que la adición de una red de comunicaciones global no mejora significativamente su rendimiento. Además, la ausencia de una red posee la ventaja de una escalabilidad más fácil. En el caso de aplicaciones con una elevada comunicación global, sin embargo, la presencia de una red de comunicaciones inter-procesador mejora el rendimiento del sistema. Para satisfacer las demandas de la aplicación, se puede incorporar fácilmente una red en el hardware básico de PiSMA, como se muestra en [7], donde PiSMA fue utilizada para ejecutar aplicaciones de propósito específico tales como Video on Demand ["vídeo a la carta"].
La tolerancia a fallos es otra característica importante de la arquitectura PiSMA; esta capacidad proviene de su estructura, mostrada en la figura 3, que proporciona caminos alternativos que pueden utilizarse cuando un componente (procesador o memoria) falla, según se describe en [9].
El modelo de programación de PiSMA distingue entre datos compartidos y privados. Los datos privados se espera que residan en una de las cuatro memorias adyacentes al procesador activo y son referenciados por un offset [desplazamiento]. Referirse a variables privadas es sencillo: el procesador presenta la dirección real en su bus y lee de la memoria apropiada. No hace falta hardware especial para realizar esta transacción; el procesador ve sus cuatro memorias vecinas como un espacio de memoria uniforme y contiguo. Cualquier compilador que referencie a los datos localmente en el segmento de datos (como hace la mayoría de compiladores) se puede utilizar para manejar este tipo de datos.
Los datos compartidos pueden o pueden no estar en una memoria adyacente y siempre se referencian a través de punteros de indirección. Cuando el programa de aplicación se ejecuta, los datos compartidos pueden ser directamente accesibles (si residen en una memoria adyacente al procesador activo), o pueden ser alcanzados remotamente (vía paso de mensajes). Por lo tanto, no es posible referirse directamente a este tipo de datos de una forma absoluta, puesto que su localización en el sistema antes del tiempo de ejecución es desconocida.
El compilador de aplicaciones genera el código apropiado para utilizar este esquema de acceso. Para cada recurso compartido en la aplicación se reservan los respectivos punteros de indirección. Tras ello, los recursos compartidos se referencian a través de estos punteros.
El contenido de los punteros de indirección no está definido en tiempo de compilación. En tiempo de ejecución (más específicamente, durante la distribución del trabajo sobre la malla de PiSMA) se establece la localización de las variables compartidas cuando se utilizan por primera vez y se inicializan los punteros de indirección asociados.
Cuando una variable compartida es directamente accesible por un procesador, el puntero de indirección correspondiente contiene su dirección física en una de las cuatro memorias adyacentes. El procesador activo ejecuta simplemente un acceso indirecto a su espacio de memoria, al que está físicamente conectado. De esta forma no hay intervención especial del hardware ni del software: a los datos compartidos se accede como a los datos locales.
Éste no es el caso cuando los recursos de datos compartidos son remotos al procesador activo. El valor contenido en el puntero de indirección en este caso es una dirección de memoria especial, especificada para generar una excepción del SO. El puntero de indirección contiene información adicional acerca de la localización en el sistema del dato compartido, tal como el módulo físico de la memoria, la dirección y el estado de uso de este recurso compartido particular. La rutina llamada de servicio de interrupción del SO traduce la petición en un mensaje de petición de datos remotos, utilizando la información del puntero de indirección acerca de la localización del recurso.
Debe quedar claro que la arquitectura PiSMA no utiliza un esquema puro de espacio global de direccionamiento de memoria virtual, donde las direcciones generadas describen unívocamente una localización física en el espacio completo de la memoria virtual y un mecanismo hardware de traducción existe para asociar esas direcciones a su espacio físico. En lugar de eso, PiSMA utiliza direcciones físicas al acceder a los datos directamente y confía en un mecanismo software de traducción para generar los mensajes de las peticiones de datos remotos.
PiSMA requiere que sus datos tengan una localización física fija en la memoria de sistema cuando se utilizan, pues no es una arquitectura COMA [11]. La localización fija de los recursos de datos en uso evita problemas de la coherencia de los datos y no requiere mensajes globales de invalidación de datos.
Los mensajes son remitidos a su destino por conmutación de paquetes de procesador a procesador. Cada mensaje incluye una cabecera que describe su tipo, la localización de su procesador de destino en la malla y su origen (si resulta necesario). La ruta del mensaje a través de la malla de procesadores no está preestablecida cuando se genera el mensaje. Cada procesador, en la recepción de un mensaje, decide a remitirlo a uno de sus ocho procesadores vecinos o consumirlo él mismo. La dirección de expedición se encuentra comparando la localización del procesador de destino, en la cabecera de mensaje, con la propia localización del procesador de la expedición (se asume que cada procesador conoce su propia localización).
El paso de mensajes impone siempre un elevado tiempo de espera a la ejecución de la aplicación. Los mensajes mantenidos en memoria principal no son cacheables por su naturaleza y las operaciones de lectura o escritura de mensajes consumen muchos ciclos de la ejecución. El timepo empleado para el manejo de mensajes en cada procesador es otra fuente de overhead, retrasando la ejecución de la aplicación. La arquitectura PiSMA intenta minimizar la latencia del paso de mensajes evitando éste u ocultando aquélla. En el primer caso, se usa la ventaja de la comunicación física a través de memorias adyacentes comunes, evitando la generación de mensajes. Los procesadores que trabajan con recursos compartidos en una memoria común pueden ejecutarse muy rápidamente, sin la intervención de mensajes. Es responsabilidad del algoritmo de la difusión asignar gránulos del trabajo con recursos compartidos a procesadores vecinos, aunque la distribución eficiente de procesos no es siempre posible. A veces, el algoritmo de difusión tiene insuficiente información para realizar una distribución óptima del trabajo y, en otras ocasiones, la aplicación paralela no permite la distribución de sus datos en distintas memorias del sistema. El resultado es un aumento en el tráfico de mensajes (que podría ser excesivo). Para minimizar el impacto de tal situación, el sistema operativo de PiSMA se diseña para hacer swapping de los procesos que esperan datos remotos. De esta manera el procesador puede ejecutar algo útil, ocultando así el tiempo de espera.
Dimitris Lioupis (lioupis@cti.gr)
es profesor asociado en el Departamento de Ingeniería de Computadores
e Informática de la Universidad de Patras, Grecia. Andreas Pipis
(pipis@cti.gr), Maria Smirli (smirli@cti.gr)
y Michael Stefanidakis (mistral@cti.gr)
son estudiantes de doctorado en el Departamento de Ingeniería de
Computadores e Informática de la Universidad de Patras, Grecia.
¿Quiere más artículos de Crossroads acerca de Arquitectura de Computadores? Vaya al índice o al siguiente.
Copyright 1999 Dimitris Lioupis, Andreas Pipis, Maria Smirli, y Michael Stefanidakis
Última modificación:
Localización del original en inglés:
www.acm.org/crossroads/espanol/xrds5-3/pisma.html
