Jean Zay : exécution d'un travail multi GPU MPI CUDA-aware et GPUDirect en batch

Les travaux sont gérés sur l'ensemble des nœuds par le logiciel Slurm .

Pour soumettre un travail distribué multi GPU MPI CUDA-aware et GPUDirect en batch sur Jean Zay, il faut créer un script de soumission en vous inspirant des deux exemples donnés ci-dessous.

ATTENTION : il est nécessaire d'exécuter le code en utilisant la même bibliothèque OpenMPI CUDA-aware que celle que vous avez utilisée pour compiler votre code. De plus, l'utilisation de la fonctionnalité MPI CUDA-aware GPUDirect sur Jean Zay impose de respecter un ordre d'initialisation bien précis pour CUDA ou OpenACC et MPI dans le code. Veuillez vous référer à la page MPI CUDA-aware et GPUDirect.

  • Pour une exécution utilisant 3 GPU (sur un même nœud) de la partition gpu par défaut :

    multi_gpu_mpi_cuda-aware.slurm
    #!/bin/bash
#SBATCH --job-name=multi_gpu_mpi_cuda-aware     # nom du job
# Il est possible d'utiliser une autre partition que celle par défaut
# en activant l'une des 5 directives suivantes :
##SBATCH -C v100-16g                 # decommenter pour reserver uniquement des GPU V100 16 Go
##SBATCH -C v100-32g                 # decommenter pour reserver uniquement des GPU V100 32 Go
##SBATCH --partition=gpu_p2          # decommenter pour la partition gpu_p2 (GPU V100 32 Go)
##SBATCH -C a100                     # decommenter pour la partition gpu_p5 (GPU A100 80 Go)
# Ici, reservation de 3x10=30 CPU (pour 3 taches) et de 3 GPU (1 GPU par tache) sur un seul noeud :
#SBATCH --nodes=1                    # nombre de noeud
#SBATCH --ntasks-per-node=3          # nombre de tache MPI par noeud (= nombre de GPU par noeud)
#SBATCH --gres=gpu:3                 # nombre de GPU par noeud (max 8 avec gpu_p2, gpu_p5)
# Le nombre de CPU par tache doit etre adapte en fonction de la partition utilisee. Sachant
# qu'ici on ne reserve qu'un seul GPU par tache (soit 1/4 ou 1/8 des GPU du noeud suivant
# la partition), l'ideal est de reserver 1/4 ou 1/8 des CPU du noeud pour chaque tache:
#SBATCH --cpus-per-task=10           # nombre de CPU par tache (1/4 du noeud ici)
##SBATCH --cpus-per-task=3           # nombre de CPU par tache pour gpu_p2 (1/8 du noeud 8-GPU)
##SBATCH --cpus-per-task=8           # nombre de CPU par tache pour gpu_p5 (1/8 du noeud 8-GPU)
# /!\ Attention, "multithread" fait reference a l'hyperthreading dans la terminologie Slurm
#SBATCH --hint=nomultithread         # hyperthreading desactive
#SBATCH --time=00:10:00              # temps d’execution maximum demande (HH:MM:SS)
#SBATCH --output=multi_gpu_mpi%j.out # nom du fichier de sortie
#SBATCH --error=multi_gpu_mpi%j.out  # nom du fichier d'erreur (ici commun avec la sortie)
 
# Nettoyage des modules charges en interactif et herites par defaut
module purge
 
# Decommenter la commande module suivante si vous utilisez la partition "gpu_p5"
# pour avoir acces aux modules compatibles avec cette partition
#module load cpuarch/amd
 
# Chargement des modules
module load ...
 
# Echo des commandes lancees
set -x
 
# Pour la partition "gpu_p5", le code doit etre compile avec les modules compatibles
# Execution du code
srun ./executable_multi_gpu_mpi_cuda-aware
  • Pour une exécution utilisant 8 GPU (soit 2 nœuds complets) sur la partition gpu par défaut :

    multi_gpu_mpi_cuda-aware.slurm
    #!/bin/bash
#SBATCH --job-name=multi_gpu_mpi_cuda-aware     # nom du job
# Il est possible d'utiliser une autre partition que celle par défaut
# en activant l'une des 5 directives suivantes :
##SBATCH -C v100-16g                 # decommenter pour reserver uniquement des GPU V100 16 Go
##SBATCH -C v100-32g                 # decommenter pour reserver uniquement des GPU V100 32 Go
##SBATCH --partition=gpu_p2          # decommenter pour la partition gpu_p2 (GPU V100 32 Go)
##SBATCH -C a100                     # decommenter pour la partition gpu_p5 (GPU A100 80 Go)
# Ici, reservation de 8x10=80 CPU (4 taches par noeud) et de 8 GPU (4 GPU par noeud) sur 2 noeuds :
#SBATCH --ntasks=8                   # nombre total de tache MPI
#SBATCH --ntasks-per-node=4          # nombre de tache MPI par noeud (= nombre de GPU par noeud)
#SBATCH --gres=gpu:4                 # nombre de GPU par noeud (max 8 avec gpu_p2, gpu_p5)
# Le nombre de CPU par tache doit etre adapte en fonction de la partition utilisee. Sachant
# qu'ici on ne reserve qu'un seul GPU par tache (soit 1/4 ou 1/8 des GPU du noeud suivant
# la partition), l'ideal est de reserver 1/4 ou 1/8 des CPU du noeud pour chaque tache:
#SBATCH --cpus-per-task=10           # nombre de CPU par tache (un quart du noeud ici)
##SBATCH --cpus-per-task=3           # nombre de CPU par tache pour gpu_p2 (1/8 du noeud 8-GPU)
##SBATCH --cpus-per-task=8           # nombre de CPU par tache pour gpu_p5 (1/8 du noeud 8-GPU)
# /!\ Attention, "multithread" fait reference a l'hyperthreading dans la terminologie Slurm
#SBATCH --hint=nomultithread         # hyperthreading desactive
#SBATCH --time=00:10:00              # temps d'execution maximum demande (HH:MM:SS)
#SBATCH --output=multi_gpu_mpi%j.out # nom du fichier de sortie
#SBATCH --error=multi_gpu_mpi%j.out  # nom du fichier d'erreur (ici commun avec la sortie)
 
# Nettoyage des modules charges en interactif et herites par defaut
module purge
 
# Decommenter la commande module suivante si vous utilisez la partition "gpu_p5"
# pour avoir acces aux modules compatibles avec cette partition
#module load cpuarch/amd
 
# Chargement des modules
module load ...
 
# Echo des commandes lancees
set -x
 
# Pour la partition "gpu_p5", le code doit etre compile avec les modules compatibles
# Execution du code
srun ./executable_multi_gpu_mpi_cuda-aware

Puis soumettre le script via la commande sbatch : 

$ sbatch multi_gpu_mpi_cuda-aware.slurm

Remarques :

  • Les exécutions sur la partition gpu_p2 se font de manière analogue, en spécifiant --partition=gpu_p2 et --cpus-per-task=3.
  • Les exécutions sur la partition gpu_p5 se font de manière analogue, en spécifiant -C a100 et --cpus-per-task=8. Attention : les modules accessibles par défaut ne sont pas compatibles avec cette partition, il est nécessaire de charger préalablement le module cpuarch/amd pour pouvoir lister et charger les modules compatibles. Pour en savoir plus, consultez la section Modules compatibles avec la partition gpu_p5.
  • Nous vous recommandons de compiler et d'exécuter votre code dans un même environnement en chargeant les mêmes modules.
  • Dans cet exemple, on suppose que l'exécutable executable_multi_gpu_mpi_cuda-aware se situe dans le répertoire de soumission, c'est-à-dire le répertoire dans lequel on entre la commande sbatch.
  • Le fichier de sortie du calcul multi_gpu_mpi<numero_job>.out se trouve également dans le répertoire de soumission. Il est créé dès le début de l'exécution du travail; l'éditer ou le modifier pendant le déroulement du travail peut perturber celui-ci.
  • Le module purge est rendu indispensable par le comportement par défaut de Slurm : les modules que vous avez chargés dans votre environnement au moment où vous lancez sbatch sont pris en compte dans le job soumis, rendant l'exécution de votre job dépendant de ce que vous aurez fait avant.
  • Pour éviter les erreurs de distribution automatique de tâches, nous vous recommandons d'utiliser srun pour exécuter votre code au lieu de mpirun, ce qui permet de garantir une distribution conforme aux spécifications de ressources demandées dans votre fichier de soumission.
  • Les jobs ont tous des ressources définies dans Slurm par une partition et une “Qualité de Service” QoS (Quality of Service) par défaut. Vous pouvez en modifier les limites en spécifiant une autre partition et/ou une QoS comme indiqué dans notre documentation détaillant les partitions et les Qos.
  • Pour les comptes multi-projets ainsi que ceux ayant des heures CPU et GPU, il est indispensable de spécifier l'attribution d'heures sur laquelle décompter les heures de calcul du job comme indiqué dans notre documentation détaillant la gestion des heures de calcul.
  • Nous vous recommandons fortement de consulter notre documentation détaillant la gestion des heures de calcul sur Jean Zay pour vous assurer que les heures consommées par vos travaux soient décomptées de la bonne attribution.
  • L'erreur CUDA failure: cuCtxGetDevice() renvoyée à l'exécution signifie probablement que vous n'avez pas respecté l'ordre d'initialisation CUDA ou OpenACC et MPI, comme indiqué dans la page MPI CUDA-aware et GPUDirect.