Redimensionamiento Dinámico de Aplicaciones Maleables mediante RMA

Redimensionamiento Din´amico de Aplicaciones Maleables mediante RMA Iker Mart´ın-´ Alvarez1, Jos´e I. Aliaga1, Maribel Castillo1 Resumen— La redimensi´on din´amica de aplicaciones maleables en computaci´on de altas prestaciones necesita mecanismos eficientes de redistribuci´on de datos que le permita adaptarse a los cambios en el n´umero de procesos, minimizando al mismo tiempo la sobrecarga de ejecuci´on y el tiempo de redimensi´on. Este trabajo explora nuevos m´etodos de comunicaci´on unilateral basados en operaciones de Acceso Remoto a Memoria (RMA) en MPI, permitiendo a los procesos recuperar datos sin la participaci´on expl´ıcita de los procesos origen. Adem´as, se introduce la estrategia Wait Targets, que permite reconfiguraciones eficientes en segundo plano con RMA, buscando minimizar su impacto en la ejecuci´on de la aplicaci´on. Estos m´etodos se han integrado en MaM, una biblioteca para redimensionar aplicaciones en tiempo de ejecuci´on, para compararlos con la redistribuci´on tradicional basada en operaciones colectivas. La evaluaci´on experimental muestra que, a pesar de su reducido impacto en las iteraciones en curso, los m´etodos unilaterales obtienen prestaciones similares a las operaciones colectivas pero nunca les superan, debido a sus elevados costes de inicializaci´on. Si este sobrecoste fuese reducido, los enfoques unilaterales podr´ıan convertirse en una alternativa competitiva, permitiendo reconfiguraciones eficientes en segundo plano sin impactar computacionalmente a la aplicaci´on. Palabras clave— HPC, Maleabilidad, MPI, Recursos Din´amicos, RMA I. Introducci´ on EN la actualidad, se ha alcanzado la era exascale en la computaci´on de altas prestaciones (HighPerformance Computing, HPC), donde las capacidades de c´alculo de los grandes sistemas contin´uan creciendo cada a˜no, como refleja la lista TOP 500 [1]. Este avance se debe principalmente a dos factores: por un lado, las mejoras en el hardware, que afectan a la memoria, almacenamiento, redes de comunicaci´on, y el nivel de paralelismo en los procesadores; y por otro, el desarrollo de nuevos modelos de programaci´on, runtimes y bibliotecas que sean capaces de explotar estas tecnolog´ıas. Sin embargo, m´ultiples estudios revelan que a´un existen desaf´ıos para maximizar la utilizaci´on de los recursos en sistemas HPC, destacando aspectos como el uso eficiente de las CPUs, las GPUs y la memoria [2]. As´ı, es com´un encontrar trabajos que soliciten m´as nodos de los necesarios, para implementar t´ecnicas de tolerancia a fallos [3], o que no logren aprovechar todos los recursos asignados durante sus distintas fases de ejecuci´on. Esta ineficiencia se agrava en situaciones donde ciertos nodos permanecen inactivos mientras otros trabajos esperan recursos, evidenciando as´ı la necesidad de mejorar la gesti´on de estos sistemas. La gesti´on din´amica de recursos permite que los 1Dpto. de Ingenier´ıa y Ciencia de los Computadores, Universitat Jaume I de Castell´o, e-mails: [email protected], [email protected],[email protected] trabajos modifiquen, en tiempo de ejecuci´on, el n´umero de recursos que tienen asignados siempre y cuando el gestor de recursos (Resource Manager System, RMS) y las aplicaciones puedan adaptarse a estos cambios. Esta capacidad ha demostrado ser una estrategia eficaz para mejorar el uso de infraestructuras HPC de acuerdo a diferentes objetivos espec´ıficos de optimizaci´on. Entre los principales objetivos se encuentran la maximizaci´on de la utilizaci´on de recursos [4], el aumento de la eficiencia computacional [5] o energ´etica [6], [7], y el incremento del rendimiento en operaciones de I/O [8]. Desde la perspectiva de la aplicaci´on, esta capacidad de adaptaci´on se conoce como maleabilidad [9]. En este trabajo, este concepto se define como la capacidad de una aplicaci´on paralela distribuida para redimensionarse din´amicamente, modificando, tantas veces como sea necesario, el n´umero de procesos MPI [10] asignados durante su ejecuci´on. Esta flexibilidad permite mejorar el rendimiento de la aplicaci´on al ampliar los recursos asignados, cuando estos son abundantes, o liberar recursos en situaciones de alta demanda, reduciendo as´ı el tiempo de espera de otros trabajos del sistema. Adem´as, facilita la asignaci´on del n´umero ´optimo de recursos a la aplicaci´on siempre que las condiciones lo permitan. La maleabilidad se activa en puntos de control espec´ıficos de la aplicaci´on. Estos pueden localizarse al inicio o al final de una iteraci´on en una aplicaci´on iterativa, o al inicio de una fase en una aplicaci´on m´as general. Su activaci´on desencadena la ejecuci´on de una serie de etapas: 1. Reasignaci´on de recursos: El RMS decide si debe redimensionar el trabajo seg´un una pol´ıtica de asignaci´on de recursos din´amica [11], [12]. Si no es el caso, el resto de etapas no se realizan. 2. Gesti´on de procesos. La decisi´on del RMS determina si se crean o finalizan procesos MPI. Los procesos previos a la redimensi´on se consideran sources, mientras que los que contin´uan tras la misma son targets. 3. Redistribuci´on de datos: En la que se realiza la transferencia de datos entre procesos. 4. Reanudar la ejecuci´on. Al final, la aplicaci´on continua su ejecuci´on con los procesos target. El orden presentado corresponde con una reconfiguraci´on en la que la gesti´on de procesos crea target procesos y elimina source procesos. Pero la utilizaci´on de t´ecnicas m´as eficientes puede solapar las etapas 2 y 3, cambiando el orden de alguna de sus tareas. Las etapas 2 y 3 tienen un alto coste computacional, por lo que resulta fundamental optimizar su im- plementaci´on. Diversos trabajos previos [13], [14] han abordado este desaf´ıo, proponiendo diferentes enfoques para optimizar dichas etapas. En este art´ıculo se presenta un nuevo m´etodo para la redistribuci´on de datos en aplicaciones paralelas distribuidas, basado en el modelo de acceso remoto a memoria (Remote Memory Access, RMA), utilizando comunicaciones unilaterales [15]. Una de las principales ventajas de estas comunicaciones es que reduce significativamente el impacto sobre los procesos source, ya que estos no participan activamente en la redistribuci´on. La propuesta incluye adem´as una nueva estrategia de sincronizaci´on que tiene en cuenta el estado de los procesos target. Esta estrategia est´a dise˜nada espec´ıficamente para optimizar las reconfiguraciones en segundo plano, ya que permite que la aplicaci´on contin´ue ejecut´andose mientras se realiza la redistribuci´on de datos. Este trabajo presenta en detalle el dise˜no, la implementaci´on y la evaluaci´on de los m´etodos y estrategia mencionados, destacando sus ventajas y sus limitaciones en t´erminos de rendimiento y eficiencia, en comparaci´on con los m´etodos tradicionales de redistribuci´on de datos. Siguiendo estos comentarios, sus principales contribuciones son las siguientes: Dise˜no de dos m´etodos de redistribuci´on de datos basados en comunicaciones unilaterales. Dise˜no de la estrategia de sincronizaci´on Wait Targets, en la que los procesos source contin´uan su ejecuci´on hasta confirmar que los targets han finalizado la recepci´on de los datos. Evaluaci´on de las t´ecnicas presentadas en el art´ıculo, comparando sus prestaciones con otras t´ecnicas ya presentadas en estudios previos. El resto del art´ıculo se organiza como sigue. La Secci´on II describe Proteo, el framework utilizado para llevar a cabo la maleabilidad y realizar la experimentaci´on. La Secci´on III detalla las t´ecnicas implementadas para completar la etapa 3 de maleabilidad, mientras que en la Secci´on IV se muestran los resultados obtenidos al evaluar estas t´ecnicas sobre un cl´uster con 8 nodos. Finalmente, la Secci´on V presenta las conclusiones del estudio. II. Proteo A. Descripci´on general Proteo es un framework ampliamente configurable dise˜nado para facilitar el desarrollo de benchmarks utilizados en el an´alisis de los efectos de la integraci´on de la maleabilidad en aplicaciones reales [16]. Su flexibilidad permite evaluar el impacto de la maleabilidad en el rendimiento de aplicaciones en grandes sistemas, comparando diferentes alternativas. La Figura 1 muestra la arquitectura interna de Proteo, que se compone de dos m´odulos principales: el M´odulo de Aplicaci´on Sint´etica (SAM) y el M´odulo de Maleabilidad (MaM). El m´odulo SAM est´a dise˜nado para emular el comportamiento computacional de cualquier aplicaci´on paralela basada en MPI, utilizando los par´ametros almacenados en un archivo Fig. 1: Arquitectura de Proteo de configuraci´on. Esta funcionalidad permite reproducir cargas de trabajo sint´eticas similares al comportamiento de aplicaciones reales, facilitando as´ı su evaluaci´on en distintos escenarios. Por su parte, el m´odulo MaM se encarga de la reconfiguraci´on din´amica de las aplicaciones, ajustando el n´umero de procesos en ejecuci´on e implementando todas las etapas de la maleabilidad, especialmente la 2 y la 3. La combinaci´on de ambos m´odulos permite que SAM emule el comportamiento de un aplicaci´on con diferentes configuraciones, mientras que MaM realiza la transici´on entre configuraciones. De este modo se facilita la evaluaci´on de t´ecnicas de maleabilidad en una aplicaci´on real sin necesidad de implementarlas directamente sobre la original, lo que resulta especialmente valioso para buscar la mejor alternativa, dado que esta tarea suele ser muy compleja. MaM tambi´en cuenta con una interfaz especializada [17] que simplifica la incorporaci´on de estas t´ecnicas en aplicaciones paralelas reales, proporcionando as´ı una soluci´on vers´atil para evaluar y aplicar la maleabilidad en diversos entornos computacionales. Adem´as de los m´odulos principales, Proteo cuenta con subm´odulos de monitorizaci´on que registran m´etricas de rendimiento de las aplicaciones emuladas o evaluadas. Esta informaci´on es muy valiosa para analizar el impacto de la maleabilidad sobre la utilizaci´on de recursos y la eficiencia de la ejecuci´on. La informaci´on recopilada se almacena en archivos de salida para su posterior an´alisis, lo que convierte a Proteo en una herramienta esencial para investigadores y desarrolladores que trabajan en aplicaciones paralelas din´amicas. B. MaM El m´odulo MaM implementa las distintas etapas que conforman el proceso de maleabilidad en aplicaciones paralelas, abordando tanto la gesti´on de procesos como la redistribuci´on de datos. Para cada una de estas etapas, MaM proporciona una serie de m´eto- dos y estrategias que permiten adaptar el proceso de reconfiguraci´on seg´un las necesidades del entorno de ejecuci´on. En cada etapa es obligatorio seleccionar un ´unico m´etodo, el cual define c´omo se llevar´a a cabo la operaci´on correspondiente. Por su parte, las estrategias son opcionales y pueden combinarse libremente para optimizar el rendimiento y la eficiencia del sistema. A continuaci´on, se describen las t´ecnicas implementadas en MaM que han sido empleadas en este estudio. En la gesti´on de procesos, el m´odulo MaM parte de un grupo inicial compuesto por NS procesos source y un nuevo grupo formado por NT procesos target, permitiendo que un mismo proceso pueda pertenecer a ambos grupos durante la reconfiguraci´on. De todos los m´etodos y estrategias que implementa MaM para completar la redimensi´on [13], en este estudio se emplea exclusivamente el m´etodo Merge. Por lo tanto, si (NT > NS), se generan (NT −NS) procesos nuevos, mientras que si (NS > NT ), se eliminan (NS −NT) procesos. Este m´etodo, originalmente propuesto en Flex-MPI [18], ha sido modificado en MaM para eliminar la limitaci´on que imped´ıa reducir el n´umero de procesos por debajo del valor inicial con el que se lanza la aplicaci´on. Durante la etapa de redistribuci´on de datos, el m´odulo MaM permite transferir informaci´on de forma eficiente y semiautom´atica entre los procesos source ytarget, tanto con datos escalares como con estructuras unidimensionales, y admitiendo tipos primitivos o derivados de MPI. Para ello, los datos se clasifican en dos categor´ıas: constantes ovariables. Los constantes no se modifican durante la ejecuci´on de la aplicaci´on, por lo que pueden transferirse utilizando operaciones bloqueantes o no bloqueantes, seg´un convenga, para maximizar las prestaciones de la aplicaci´on. Por su parte, los variables se modifican a la largo de la ejecuci´on, por lo que la transferencia debe realizarse con operaciones bloqueantes. MaM cuenta con diversos m´etodos implementados para llevar a cabo la redistribuci´on de datos [14]. En este estudio, se emplea uno de esos m´etodos que se basa en el uso de operaciones de comunicaci´on colectivas (Collective), espec´ıficamente la operaci´on MPI Alltoallv. Adem´as, MaM incorpora varias estrategias para optimizar este proceso: i) Threading, que facilita la redistribuci´on en segundo plano permitiendo que la operaci´on colectiva sea realizada por hilos auxiliares; ii) Non-blocking, que implementa las redistribuciones de datos en segundo plano utilizando primitivas de MPI no bloqueantes; iii) Wait Targets, una variante de la anterior en la que se incorpora una condici´on adicional para asegurar que la recepci´on de los datos se ha completado. En este trabajo se a˜naden dos nuevos m´etodos basados en RMA a MaM que completan la redistribucion de datos, y que ser´an descritos en la secci´on IIIB. Estos m´etodos pueden ser combinados con las estrategias Threading yWait Targets, que permiten que la redistribuci´on de datos se pueda ejecutar en segundo plano mientras se ejecuta la aplicaci´on. III. Redistribuci´ on de datos En esta Secci´on se indica como utilizar las primitivas RMA de MPI para realizar la redistribuci´on de datos requerida en una reconfiguraci´on. Adem´as, se introduce una nueva estrategia que permite realizar esta redistribuci´on de forma no bloqueante. A. Descripci´on general RMA La comunicaci´on mediante RMA es un modelo de programaci´on en MPI, inclu´ıdo en MPI-2 con el concepto de comunicaciones unilaterales [15]. Este modelo permite que un proceso acceda directamente a la memoria de otros procesos para intercambiar datos, a diferencia del modelo tradicional de comunicaci´on en MPI en el que es necesario una sincronizaci´on entre los procesos. Este mecanismo reduce la sobrecarga de la gesti´on de mensajes, y permite optimizar el acceso a datos en sistemas con un gran n´umero de procesos, lo que es especialmente adecuado para patrones de comunicaci´on irregulares o din´amicos. Se distinguen dos tipos de procesos en la comunicaci´on con RMA: el proceso origen y el proceso destino. El proceso destino es el que expone una regi´on de su memoria para que otro proceso pueda acceder a ella, mientras que el proceso origen es el que realiza la comunicaci´on, ya sea leyendo o escribiendo en la memoria expuesta por el proceso destino. Este modelo se estructura en tres componentes fundamentales: ventanas de memoria,operaciones remotas ymecanismos de sincronizaci´on. Las ventanas de memoria son las regiones de memoria que el proceso destino expone para que los procesos origen accedan a ellas. Existen dos tipos principales de operaciones remotas sobre los datos en una ventana: las de tipo Put (escritura) y Get (lectura). Para garantizar la coherencia de los datos, RMA proporciona mecanismos de sincronizaci´on que controlan el acceso seguro a las ventanas, asegurando que las operaciones se completen de forma ordenada y consistente. En este contexto, se introduce el concepto de ´epoca, que define el intervalo de tiempo durante el cual se permite que un proceso origen realice operaciones en las ventanas de memoria de los procesos destino. Pues bien, los mecanismos de sincronizaci´on son los que gestionan las ´epocas, delimitando claramente cu´ando se inicia y finaliza el acceso a las ventanas de memoria, lo que proporciona un entorno controlado para las comunicaciones y garantiza la coherencia en el intercambio de informaci´on. En la parte superior de la Figura 2 se muestra una operaci´on de comunicaci´on utilizando operaciones tradicionales de MPI, como Send yRecv, mientras que en la parte inferior de la misma figura aparece una comunicaci´on basada en RMA. En este ´ultimo caso, se observa que no es necesario realizar una sincronizaci´on expl´ıcita entre los procesos que participan en la comunicaci´on, por lo que el proceso origen (1) puede continuar su ejecuci´on sin depender de que el destino (0) est´e listo o no. Sin embargo, este hecho no significa que las comunicaciones RMA sean completamente as´ıncronas, ya que la definici´on Fig. 2: Diferencias de sincronizaci´on entre una llamada convencional (arriba) y una unilateral (abajo). de las ventanas requiere una sincronizaci´on, y el uso de operaciones remotas debe seguir modelos que garanticen la coherencia de los datos. Existen tres modelos principales que gestionan el acceso y la coherencia de los datos en memoria remota. (i) El modelo activo requiere que todos los procesos que han abierto ventanas participen activamente en el proceso de sincronizaci´on. Por lo tanto, todos los procesos deben coordinarse para iniciar y finalizar el intercambio de datos, garantizando as´ı que todas las modificaciones se reflejen correctamente. (ii) El modelo activo generalizado ofrece mayor flexibilidad al permitir que solo un grupo espec´ıfico de procesos participe en la sincronizaci´on. De este modo, no es necesario que todos los procesos se coordinen simult´aneamente, lo que mejora la eficiencia en patrones de comunicaci´on irregulares o din´amicos. (iii) El modelo pasivo permite que el proceso origen acceda directamente a la memoria del proceso destino sin que este ´ultimo intervenga activamente. Este enfoque es ideal cuando los procesos origen solo necesitan leer la memoria de otros procesos, como ocurre en una reconfiguraci´on maleable. El Listado 1 muestra las principales funciones para realizar transferencias usando el modelo pasivo dentro del contexto de una reconfiguraci´on maleable. As´ı, las funciones Win create yWin free crean y liberan una ventana, siendo operaciones colectivas y bloqueantes para todos los procesos en el comunicador asociado. Por su parte, la funci´on Get permite leer datos de una ventana. Mientras que las funciones Lock yUnlock abren y cierran una ´epoca en un proceso destino concreto. La llamada Lock debe incluir el tipo de acceso permitido, que puede ser SHARED oEXCLUSIVE. El primero permite que m´ultiples procesos accedan de modo simult´aneo a los datos de la ventana, mientras que el segundo restringe el acceso a un ´unico proceso. En el caso de las reconfiguraciones, se utiliza el acceso compartido, ya que ´unicamente se realizan operaciones de lectura. Adem´as, la llamada Lock debe incluir la bandera MPI MODE NOCHECK, ya que el entorno de MPI no necesita comprobar si existen accesos conflictivos. Por su parte, la llamada Unlock bloquea al proceso origen hasta que todas las operaciones dentro de una ´epoca hayan sido completadas. Adem´as, ambas funciones tienen una variante con el sufijo all, que permite definir una ´epoca como el acceso simult´aneo de un proceso origen a m´ultiples destinos sin necesidad de especificarlo individualmente. Listado 1: Funciones de MPI para comunicaciones unilaterales pasivas. 1int MPI_Win_create(...); 2int MPI_Win_free(...); 3int MPI_Get (...) ; 4int MPI_Win_lock ( int locktype , int rank , 5int assert , MPI_Win win); 6int MPI_Win_unlock(...); 7int MPI_Win_lock_all ( int assert , MPI_Win win ); 8int MPI_Win_unl ock_a ll (...) ; B. Implementaci´on en MaM En este trabajo se ha ampliado la funcionalidad de MaM, incorporando el uso del modelo pasivo de las operaciones unilaterales para realizar la redistribuci´on de datos. En este enfoque, los procesos source solo requieren que sus datos est´en disponibles en ventanas de memoria, permitiendo que los procesos target accedan directamente a sus datos sin que los source participen activamente en la comunicaci´on. Ser´a necesario sincronizar adecuadamente la apertura y el cierre de las ventanas para garantizar la coherencia de la informaci´on. La Figura 3 muestra un ejemplo de redistribuci´on de datos mediante RMA, en el que dos procesos target,YeY+1, deben obtener informaci´on desde distintos procesos source,X,X+1 y X+2. En este escenario, cada proceso source (actuando como proceso destino) define una ventana de memoria que contiene todos los datos a redistribuir, permitiendo que los procesos target (actuando como procesos origen) accedan directamente a estas ventanas para leer la informaci´on. Por su parte, un proceso target puede requerir acceder a una o m´as ventanas de memoria para obtener toda la informaci´on que necesita, por lo que es necesario conocer de antemano la informaci´on que se debe leer de cada ventana de memoria antes de iniciar la redistribuci´on de datos. El Algoritmo 1 muestra los c´alculos requeridos por los procesos target, para conocer cu´antos elementos debe leer de cada ventana de memoria. En este calculo se utilizan dos funciones: Get source group que indica el n´umero de procesos source desde los cuales se obtendr´a la informaci´on, y Block id que determina los valores ini yend, que definen el rango de elementos que cada proceso almacena en funci´on de su identificador y del n´umero de procesos en su grupo. B´asicamente, cada proceso target debe conocer qu´e elementos leer en cada source calculando la intersecci´on entre su intervalo de datos y el de los procesos source. Si no existe intersecci´on, no se realiza ninguna lectura, pero si la hay, se calcula el n´umero de elementos correspondientes y su valor se almacena en el vector counts. Adem´as, la posici´on de memoria del target en la que se deben escribir los elementos le´ıdos se registra en el vector displs. Los escalares first source ylast source almacenan, respectivamente, la primera y la ´ultima ventana a la que se debe Fig. 3: Redistribuci´on de datos con RMA. Algoritmo 1 Par´ametros de comunicaci´on en target. s size =Get source group() ini, end =Block id(myId) counts =calloc(s size) displs =calloc(s size + 1) first source =−1 for (i= 0; i < s size;i++ )do s ini, s end =Block id(i) if (ini ≥s end||end ≤s ini)then if (first source == −1) then first source =i first index =ini −s ini end if big ini =ini > s ini?ini :s ini small end =end < s end?end :s end counts[i] = small end −big ini displs[i+ 1] = displs[i] + counts[i] else if (first source! = −1) then last source =i break end if end if end for acceder, mientras que first index indica la posici´on desde la cual se debe iniciar la lectura de datos en la ventana de memoria de first source. S´olo es necesario calcular este ´ultimo valor en la primera ventana, debido a la naturaleza de la distribuci´on por bloques. Este trabajo presenta dos m´etodos para la redistribuci´on de datos mediante comunicaciones unilaterales, descritos en los Algoritmos 2 y 3. En ambos casos, la comunicaci´on se inicia con la creaci´on de una ventana por parte de todos los procesos participantes, que es vac´ıa para los procesos target e incluye los datos a redistribuir en los procesos source, y concluye con la destrucci´on de dicha ventana. La principal diferencia de ambos m´etodos es el n´umero de ´epocas utilizadas durante la operaci´on. Algoritmo 2 M´etodo RMA1: Lock+Unlock. if (proceso es target)then if (proceso es solo target)then data =NULL end if window =MPI Win create(data) first source =get first source() last source =get last source() first index =get first index() lock =MP I LOCK SHARED assert =MP I MODE NOCHECK for (i=first source;i < last source;i++ )do MPI Win lock(i, lock, assert) MPI Get(i→myId, displs[i], first index, counts[i]) first index = 0 end for for (i=first source;i < last source;i++ )do MPI Win unlock(i) end for MPI Win free(window) else window =MPI Win create(data) ... MPI Win free(window) end if Algoritmo 3 M´etodo RMA2: Lockall+Unlockall. if (proceso es target)then if (proceso es solo target)then data =NULL end if window =MPI Win create(data) first source =get first source() last source =get last source() first index =get first index() assert =MP I MODE NOCHECK MPI Win lock all(assert) for (i=first source;i < last source;i++ )do MPI Get(i→myId, displs[i], first index, counts[i]) first index = 0 end for MPI Win unlock all MPI Win free(window) else window =MPI Win create(data) ... MPI Win free(window) end if C. Modificaciones para una implementaci´on en segundo plano Los m´etodos descritos en la secci´on anterior permiten realizar la redistribuci´on de datos utilizando comunicaciones unilaterales de forma bloqueante. Esto impide que la aplicaci´on pueda continuar su ejecuci´on mientras se completa esta comunicaci´on, aumentando el coste de finalizaci´on de la aplicaci´on. En esta secci´on se presentan dos alternativas para eliminar este impedimento: el uso de Threading, o de la estrategia Wait Targets de MaM. En la primera de las alternativas, se propone crear un hilo auxiliar en cada proceso source, que sea el encargado de completar la redistribuci´on en segundo plano, utilizando el Algoritmo 2 o el Algoritmo 3. De esta forma, se libera de carga a los hilos principales, que pueden seguir ejecutando la aplicaci´on, y consultando a los hilos auxiliares si la redistribuci´on se ha completado, cuando lo consideren. La incorporaci´on de la estrateg´ıa Wait Targets en los Algoritmos 2 y 3 se inicia analizando las sincro- nizaciones que estos algoritmos incluyen. As´ı, la funci´on MPI Unlock bloquea al proceso que la utiliza hasta que todas sus operaciones MPI Get se hayan completado, mientras que la funci´on MPI Win free requiere que todos los procesos del comunicador la invoquen para completarse, actuando como una operaci´on de sincronizaci´on colectiva que bloquea tanto a los procesos que no realizan ninguna lectura como a los que ya la han completado. Si este bloqueo se realiza sobre procesos source, se impide que la aplicaci´on pueda continuar su ejecuci´on mientras la comunicaci´on se completa, aumentando el tiempo de ejecuci´on de la aplicaci´on. Para mejorar este comportamiento, se propone dividir el c´odigo de los algoritmos en dos funciones: Init RMA que inicia la redistribuci´on y llama a MPI Win create;Complete RMA que utiliza MPI Unlock para finalizar las comunicaciones y MPI Win free para liberar las ventanas de memoria. Para evitar el bloqueo que se produce en un proceso cuando se utiliza MPI Unlock, se propone utilizar la funci´on MPI Rget, que realiza la misma tarea que MPI Get, pero devolviendo un objeto MPI Request. El uso de este tipo de objetos permite controlar el estado de la operaci´on de forma no bloqueante, utilizando la funci´on MPI Test. As´ı, los procesos source pueden consultar peri´odicamente el estado de la comunicaci´on, y continuar la ejecuci´on de la aplicaci´on en el caso que la llamada a MPI Test le indique que la comunicaci´on no ha finalizado. Por su parte, evitar el bloqueo de la funci´on MPI Win free requiere conocer cuando han completado la comunicaci´on todos los procesos, permitiendo que los procesos source sigan ejecutando la aplicaci´on mientras no se cumpla esta condici´on. Para resolver este problema, se propone utilizar la estrategia Wait Targets de MaM, que utiliza la funci´on MPI Ibarrier para sincronizar todos los procesos involucrados. Esta funci´on devuelve un objeto MPI Request, sobre el cual se puede utilizar la funci´on MPI Test, para hacer un control no bloqueante del estado de la comunicaci´on, o la funci´on MPI Wait, que bloquea la ejecuci´on del proceso hasta la finalizaci´on de la comunicaci´on. As´ı, todos los procesos hacen una llamada a MPI Ibarrier, pero solo los procesos source utilizan MPI Test, para poder continuar la ejecuci´on de la aplicaci´on si la comunicaci´on no ha finalizado, mientras que el resto de procesos utilizan MPI Wait, para esperar la finalizaci´on de la comunicaci´on. La Figura 4 muestra el diagrama de flujo que describe c´omo funciona Complete RMA cuando se incorpora la estrategia Wait Targets para realizar en segundo plano una redistribuci´on utilizando comunicaciones unilaterales. Aparecen tres flujos diferentes en el diagrama, dependiendo del tipo de proceso: aquellos que s´olo son target, los que s´olo son source, y los que son source ytarget a la vez. Los procesos que s´olo son target no ejecutan la aplicaci´on, raz´on por la que pueden utilizar las funciones MPI Get,MPI Lock yMPI Unlock, aunque ello suponga un bloqueo durante la redistribuci´on. Una Fig. 4: Diagrama de flujo de Complete RMA que completa una redistribuci´on en segundo plano con RMA. vez completadas todas sus lecturas, deben llamar a la MPI Ibarrier para indicar al resto de procesos que han finalizado, y luego utilizar MPI Wait(Ibarrier), bloque´andose de nuevo, para esperar a que el resto de procesos tambi´en finalicen sus lecturas, antes de eliminar sus ventanas de memoria. Por su parte, los procesos que solo son source no realizan ninguna lectura de datos, por lo que su primera tarea es notificarlo utilizando MPI Ibarrier. A continuaci´on, entran en un bucle en el que se ejecuta la aplicaci´on (Compute) y se realiza una verificaci´on no bloqueante del estado de las operaciones de lecturas del resto de procesos, utilizando MPI Test(Ibarrier). Una vez completada toda la redistribuci´on, se eliminan sus ventanas de memoria. Finalmente, los procesos que son tanto sources como targets realizan la lectura de datos de modo no bloqueante, utilizando MPI Rgets yMPI Locks. A continuaci´on, entran en un bucle en el que se ejecuta la aplicaci´on y se comprueba si han finalizado sus lecturas, utilizando MPI Testall(Rgets). Cuando ´estas se completan, se notifica al resto de procesos llamando a MPI Ibarrier. Entonces, vuelven a entrar en un bucle en el que se ejecuta la aplicaci´on, pero ahora la condici´on verifica de modo no bloqueante si todos los procesos han completado las lecturas utilizando MPI Test(Ibarrier). Cuando se completa la redistribuci´on, se realizan los correspondientes Unlocks y se eliminan sus ventanas de memoria. IV. Resultados experimentales En esta secci´on se presentan los experimentos y el an´alisis realizado para comparar los m´etodos descritos en la Secci´on III. A. Hardware y Software utilizados Los experimentos se han realizado en un cl´uster compuesto por ocho nodos, cada uno equipado con dos procesadores Intel Xeon 4210 de 10 n´ucleos, sumando un total de 160 n´ucleos. Los nodos est´an interconectados mediante una red InfiniBand EDR de 100 Gbps, utilizando MPICH 4.2.0 [19], compilado con CH4:OFI netmod (InfiniBand). La versi´on de Proteo utilizada se encuentra disponible p´ublicamente en un repositorio1, y los resultados de los experimentos est´an disponibles de forma p´ublica [20]. La evaluaci´on experimental utiliza SAM para emular el algoritmo del Gradiente Conjugado [21], una aplicaci´on iterativa que utiliza dos llamadas colectivas Allreduce y una Allgather. El tama˜no del problema utilizado requiere aproximadamente 64 GB de memoria. Para permitir un correcto estudio estad´ıstico, los experimentos se han repetido 20 veces y se ha calculado la mediana de los resultados. Cada experimento incluye una ´unica reconfiguraci´on, que parte de NS procesos source aNT procesos target. Dado que tanto NS como NT toman valores en el conjunto 20,40,40,160, aparecen un total de 12 combinaciones diferentes. Por su parte, el n´umero de nodos utilizados en cada ejecuci´on se determina con la f´ormula ⌈N/20⌉, donde Nes el mayor valor entre NS yNT, para optimizar as´ı el consumo de recursos usados en el sistema. La reconfiguraci´on que aparece en cada experimento hacen uso de MaM, configurado como sigue. Para la gesti´on de procesos, se utiliz´o el m´etodo Merge en todos los experimentos, siempre en modo s´ıncrono y bloqueante. En cambio, para la redistribucion de datos, se evaluaron diferentes m´etodos y estrategias. Los m´etodos considerados fueron: COL (Collective de MaM), RMA1 (Algoritmo 2), y RMA2 (Algoritmo 3). Adem´as, cuando los m´etodos se ejecutaron de modo as´ıncrono, se consideraron las estrategias Threading (T), Non-Blocking (NB), y Wait Targets (WT) para el primer m´etodo, y las estrategias Threading yWait Targets para los ´ultimos dos m´etodos. B. Tiempos de redistribuci´on bloqueantes La Figura 5 muestra el tiempo necesario (en segundos) para realizar la redistribuci´on, considerando las distintas versiones bloqueantes y variando el n´umero de procesos source ytarget involucrados. De su an´alisis, se observa que los m´etodos RMA1 y RMA2 presentan un comportamiento muy similar, siendo sus prestaciones ligeramente inferiores a las de COL, obteniendo una degradaci´on m´ınima de 1,013×al expandir de 20 a 80 y una m´axima de 1,377×al reducir de 80 a 20 procesos. Este comportamiento se justifica, principalmente, por el coste de creaci´on de las ventanas de memoria, una operaci´on colectiva y bloqueante entre todos los procesos. Por tanto, la elecci´on entre los m´etodos RMA tiene poco impacto sobre el rendimiento cuando se utiliza en modo bloqueante. 1https://lorca.act.uji.es/gitlab/martini/ malleability_benchmark/-/tree/Sarteco25 Fig. 5: Tiempos de reconfiguraci´on en versiones bloqueantes. C. Tiempos de redistribuci´on en segundo plano En esta secci´on se realiza un estudio m´as detallado del comportamiento de las versiones as´ıncronas, considerando los diferentes m´etodos (COL, RMA1 y RMA2) con las estrategias asociadas (T, NB, WT). El primer estudio analiza el impacto de ejecutar la aplicaci´on simult´aneamente con la redistribuci´on en segundo plano. Para evaluar este efecto, se calcula la relaci´on entre el tiempo de ejecuci´on de una iteraci´on sin redistribuci´on y el tiempo de ejecuci´on de la misma iteraci´on cuando se realiza una redistribuci´on en segundo plano. A esta relaci´on se le denomina ω. La Figura 6 muestra como var´ıa ωen funci´on del m´etodo y estrategia utilizados, y considerando diferentes combinaciones del n´umero de procesos source ytarget. As´ı, las versiones que emplean hilos auxiliares (T) son las m´as afectadas, con incrementos de ω superiores a 100 en las variantes de RMA y valores comprendidos entre 43 y 123 para COL. Estos incrementos se justifican por la aparici´on de oversubscription en los nodos donde residen los procesos source, que ralentiza la ejecuci´on de los hilos principales. Para un an´alisis m´as detallado de las versiones NB y WT, en la Figura 7 se muestra como var´ıan estas estrategias, sin considerar las variantes T. La primera conclusi´on es que las versiones de RMA son las que mejores resultados presentan, con valores de ωcercanos a 1 en la mayor´ıa de los casos, siendo 2,8 el peor caso. La raz´on que lo justifica es que el n´umero de procesos involucrados en la comunicaci´on en estos m´etodos es siempre igual a NT mientras que en las variantes de COL este n´umero es igual a m´ax(NS, NT). Adem´as, los procesos involucrados en RMA no necesitan ninguna sincronizaci´on, salvo tras completarse MPI Ibarrier. Una segunda conclusi´on es que RMA2-WT siempre obtiene valores iguales o inferiores a RMA1-WT, debido a la reducci´on del n´umero de ´epocas generadas al utilizar Lock all. Adem´as, las reconfiguraciones que presentan mayores valores de ωen estas variantes son las reducciones a 20 o 40 procesos target, que puede justificarse por la alta congesti´on generada en las comunicaciones. La Figura 8 muestra el n´umero total de iteraciones realizadas mientras la redistribuci´on en segundo plano est´a en curso, en funci´on de la versi´on utilizada y del n´umero de procesos source ytarget. El impacto Fig. 6: Incremento del coste de iteraciones (ω) en versiones en segundo plano. Fig. 7: Incremento del coste de iteraciones (ω) en versiones NB y WT. real sobre el tiempo de finalizaci´on de la aplicaci´on de este estudio debe considerar de modo combinado el n´umero de iteraciones junto con el valor de ωy de los procesos implicados, es decir NS yNT . La principal conclusi´on del an´alisis de esta figura es que las versiones COL-NB y COL-WT son las que realizan m´as iteraciones. Adem´as, los valores m´as altos se justifican con altos niveles de congesti´on en la comunicaci´on, como en el caso (20,160) que alcanza un n´umero de iteraciones igual a 24, lo cual tiene sentido. En cambio, el resto de versiones tiene un n´umero de iteraciones entre 1 y 3, independientemente del n´umero total de procesos involucrados, lo cual se considera un comportamiento inesperado. Un an´alisis detallado de la ejecuci´on de la variante COL-T muestra que la raz´on que justifica el n´umero tan bajo de iteraciones es que la aplicaci´on se bloquea al ejecutar la operaci´on Allgather. Dado que la redistribuci´on la realiza el hilo auxiliar y que el entorno MPI se ha iniciado con el soporte para hilos (MPI THREAD MULTIPLE), no hay ninguna raz´on que justifique que la hebra principal se bloquee. Por tanto, se concluye que la versi´on de MPICH utilizada puede incluir alguna limitaci´on. Respecto al an´alisis de las variantes RMA, la mayor parte de su coste se invierte en la creaci´on de las ventanas de memoria, que es una operaci´on colectiva en la que participan tanto procesos source como target. Durante todo el tiempo que se realiza esta operaci´on, se completa la mayor´ıa de las lecturas de datos, por lo que el n´umero de iteraciones podr´ıa ser Fig. 8: Total de iteraciones durante una redistribuci´on en segundo plano. igual a uno, pero el n´umero final obtenido depende de la variante utilizada. En el caso de las variantes WT, una vez los procesos target han terminado sus lecturas, deben realizar un MPI Ibarrier y posteriormente hacer un MPI Test(Ibarrier), operaciones que el entorno MPI dif´ıcilmente puede sincronizar adecuadamente en la misma iteraci´on, raz´on por la que el n´umero de iteraciones es igual a dos en la mayor´ıa de las combinaciones. Por lo que respecta a las variantes T, el problema se agrava a´un m´as con el sobrecoste asociado al oversubscription, lo que provoca que el n´umero de iteraciones en todas las combinaciones sea igual a tres. D. Comparativa de la redistribuci´on bloqueante y de la redistribuci´on en segundo plano El ´ultimo an´alisis pretende determinar el impacto que las dos variantes de redistribuci´on, bloqueante y en segundo plano, tiene sobre el funcionamiento de la aplicaci´on. Comparar ´unicamente el tiempo total de cada variante puede no ser suficiente, ya que dicho enfoque ignora el efecto que la redistribuci´on tiene sobre el progreso normal de la aplicaci´on. Una mejor alternativa ser´ıa calcular cu´ando la aplicaci´on alcanza la misma iteraci´on usando ambos tipos de redistribuci´on, es decir, cuando la aplicaci´on utilizando la variante bloqueante alcanza la iteraci´on obtenida al finalizar la variante en segundo plano. Las ecuaciones 1 y 2 calculan, respectivamente, el tiempo total para la redistribuci´on bloqueante (TBl total) y para la redistribuci´on en segundo plano (TSP total), considerando en ambos casos que la reconfiguraci´on se inicia en la misma iteraci´on. TBl total =TBl redis +TN T it ∗m´ın variantes(NN S→NT it ) (1) TSP total =TSP redis (2) El primer termino en ambas ecuaciones, TBl redis y TSP redis, representa el tiempo transcurrido desde que se inicia la redistribuci´on hasta que finaliza. Por su parte, los t´erminos adicionales en la ecuaci´on 1 son: TNT it es el tiempo por iteraci´on para NT procesos target, y NN S→NT it es el n´umero de iteraciones que ocupa la redistribuci´on en segundo plano cuando la reconfiguraci´on va desde NS aNT procesos. De este segundo t´ermino, ´unicamente se considera el valor m´ınimo entre las medianas de todas las variantes en segundo plano. La Figura 9 muestra el tiempo obtenido al aplicar las ecuaciones 1 y 2. En esta evaluaci´on se han excluido las variantes RMA1-T y RMA2-T, por el alto valor de ωque muestran en la Figura 6, que lleva a valores entre 25 y 45 segundos al aplicar las ecuaciones. La primera conclusi´on ser´ıa que el m´etodo COL es el que obtiene mejores prestaciones en casi todos los casos, seguido por la variante COL-T que tiene un rendimiento muy similar, debido a su comportamiento semibloqueante causado por la limitaci´on de la versi´on de MPICH utilizada. De hecho, COL-T ´unicamente mejora a COL en el caso 80 a 20 procesos, con una diferencia de 0,09s. Por su parte, el comportamiento de la versi´on COL-NB es m´as irregular, ya que supera a COL en los casos 20 a 160 y 40 a 160 procesos, con una ligera diferencia de 0,07s, mientras que obtiene el valor m´as alto en las reconfiguraciones de 40 a 20 procesos y de 80 a 20, resultado de la variabilidad del coste de sus iteraciones y su impacto en ω. Finalmente, el comportamiento de COL-WT es casi id´entico al de COL-NB, con una diferencia m´axima de 0,4sen la reconfiguraci´on de 20 a 160 procesos. Por lo que respecta a las variantes basadas en comunicaciones unilaterales, se observa que sus resultados son muy parecidos, con una diferencia m´axima de 0,4s. La raz´on es el gran peso que tiene la sincronizaci´on asociada a la creaci´on de las ventanas de memoria, tanto en versi´on bloqueante como en la que se realiza en segundo plano. Dada la similitud existente entre los resultados de RMA1 y RMA2, se recomienda el uso de RMA2 por su simplicidad. La conclusi´on final de este an´alisis ser´ıa que las versiones basadas en comunicaciones unilaterales nunca superan el rendimiento de las versiones colectivas. V. Conclusiones Este trabajo introduce nuevos m´etodos y estrategias para realizar la redistribuci´on de datos durante la reconfiguraci´on de aplicaciones cient´ıficas MPI. M´as en concreto, se proponen dos nuevos m´etodos basados en comunicaciones unilaterales con RMA, lo que permite que los procesos target puedan acceder a los datos de los procesos source sin la participaci´on de estos ´ultimos. Adem´as, se introduce la estrategia Wait Targets, que permite la ejecuci´on de estos nuevos m´etodos en segundo plano, posibilitando que las aplicaciones contin´uen su ejecuci´on durante las fases de redistribuci´on. Como resultado de este trabajo se ha ampliado la capacidad y la flexibilidad de MaM con 6 nuevas variantes de redistribuci´on de datos: dos versiones bloqueantes (RMA1 y RMA2) y 4 versiones en segundo plano. Dos de ellas implementan la estrategia Threading, utilizando hilos auxiliares para realizar las comunicaci´on, mientras que las otras dos integran la estrategia Wait Targets y el uso de operaciones no bloqueantes. La principal conclusi´on de este estudio es que la combinaci´on de los nuevos m´etodos basados en comunicaci´on unilateral y de la estrateg´ıa Wait Targets permiten una ejecuci´on en segundo plano de la redistribuci´on con un bajo impacto sobre el coste de las iteraciones, con valores de ωcercanos a 1. Pero el rendimiento global de estos nuevos m´etodos no supera el de la versi´on colectiva, debido al alto coste de la creaci´on de las ventanas, cuesti´on que requerir´a ajustes en el m´etodo que se abordar´a como trabajo futuro. Tambi´en se ha analizado el impacto de la estrategia Wait Targets cuando se aplica junto al m´etodo basado en operaciones colectivas no bloqueantes. Esta combinaci´on asegura la finalizaci´on de la redistribuci´on de datos antes de completar la ejecuci´on de los procesos source, pero a cambio de incrementar el coste de la operaci´on. El trabajo futuro, adem´as de analizar como reducir el coste de creaci´on de las ventanas de memoria en comunicaciones unilaterales, tambi´en abordar´a mejoras de la estrategia Wait Targets que eviten que la detecci´on de la finalizaci´on de MPI Ibarrier incremente el n´umero de iteraciones implicadas en una redistribuci´on en segundo plano. De modo adicional, se investigar´a c´omo reducir el volumen de la comunicaci´on en la redistribuci´on de datos cuando la gesti´on de procesos utilice el m´etodo Merge, permitiendo que los procesos que son source ytarget conserven el mayor n´umero de datos. Agradecimientos El presente trabajo ha sido subvencionado por el proyecto PID2023-146569NB-C22, financiado por MCIN/AEI/10.13039/501100011033 y ERDF/UE. El investigador I. Mart´ın-´ Alvarez fue subvencionado por la ayuda predoctoral ACIF/2021/260, financiada por el Gobierno Auton´omico Valenciano y por la European Social Funds. Referencias [1] Jack Dongarra and Piotr Luszczek, TOP500, pp. 2055– 2057, Springer US, Boston, MA, 2011. [2] Jie Li, George Michelogiannakis, Brandon Cook, Dulanya Cooray, and Yong Chen, “Analyzing Resource Utilization in an HPC System: A Case Study of NERSC’s Perlmutter,” in High Performance Computing, Cham, 2023, pp. 297–316, Springer Nature Switzerland. [3] Atsushi Hori, Kazumi Yoshinaga, Thomas Herault, Aur´elien Bouteiller, George Bosilca, and Yutaka Ishikawa, “Overhead of Using Spare Nodes,” The International Journal of High Performance Computing Applications, vol. 34, no. 2, pp. 208–226, 2020. [4] Mohak Chadha, Jophin John, and Michael Gerndt, “Extending SLURM for dynamic resource-aware adaptive batch scheduling,” CoRR, vol. abs/2009.08289, 2020. [5] Sergio Iserte, High-throughput Computation through Efficient Resource Management, Ph.D. thesis, Universitat Jaume I, Castell´o de la Plana, Nov. 2018. [6] Sergio Iserte and Krzysztof Rojek, “A Study of the Effect of Process Malleability in the Energy Efficiency on GPUbased Clusters,” The Journal of Supercomputing, pp. 1–20, Oct. 2019. [7] Alberto Cascajo, Alvaro Arbe, Javier Garcia-Blas, Jesus Carretero, and David E. Singh, “Malleable Techniques and Resource Scheduling to Improve Energy Efficiency in Parallel Applications,” in High Performance Computing, Cham, 2023, pp. 16–27, Springer Nature Switzerland.