Jean Zay : Utilisation de CUDA MPS

Le service multi-processus MPS (Multi-Process Service) est une variante d'implémentation compatible de l'interface de programmation CUDA. L'architecture d'exécution MPS est conçue pour permettre aux applications CUDA coopératives multi-processus, généralement pour les travaux MPI, d'utiliser les fonctionnalités Hyper-Q sur les tous derniers GPU NVIDIA. Hyper-Q permet de traiter simultanément des noyaux CUDA sur le même GPU, ce qui peut améliorer les performances lorsque la capacité de calcul du GPU est sous-utilisée par un seul processus d'application.

Le service CUDA MPS est inclus par défaut dans les différents modules CUDA mis à dispositions des utilisateurs.

Pour un travail distribué multi GPU MPI en batch, l'utilisation de CUDA MPS peut être activée via l'option -C mps. Le nœud devra être réservé de manière exclusive via l'option --exclusive.

• Pour une exécution via la partition gpu par défaut (nœuds de 40 cœurs physiques et 4 GPU) utilisant un seul nœud de calcul :
  
  

  mps_multi_gpu_mpi.slurm

  #!/bin/bash
  #SBATCH --job-name=gpu_cuda_mps_multi_mpi     # nom du job
  #SBATCH --ntasks=40                   # nombre total de tache MPI
  #SBATCH --ntasks-per-node=40          # nombre de tache MPI par noeud (tous les cœurs physiques)
  #SBATCH --gres=gpu:4                  # nombre de GPU par nœud (tous les GPU)
  #SBATCH --cpus-per-task=1             # nombre de coeurs CPU par tache
  # /!\ "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=gpu_cuda_mps_multi_mpi%j.out # nom du fichier de sortie
  #SBATCH --error=gpu_cuda_mps_multi_mpi%j.out  # nom du fichier d'erreur (ici commun avec la sortie)
  #SBATCH --exclusive                   # on réserve le noeud de manière exclusive 
  #SBATCH -C mps                        # le service MPS est activé   
   
  # nettoyage des modules charges en interactif et herites par defaut
  module purge
   
  # chargement des modules
  module load ...
   
  # echo des commandes lancees
  set -x
   
  # execution du code avec binding via bind_gpu.sh : 4 GPU pour 40 taches MPI.
  srun ./executable_multi_gpu_mpi

Puis soumettre le script via la commande sbatch :

$ sbatch mps_multi_gpu_mpi.slurm

• Une exécution sur un nœud complet de la partition gpu_p2 (nœuds de 24 cœurs physiques et 8 GPU) se fait de manière analogue, en spécifiant :

  #SBATCH --partition=gpu_p2            # partition GPU choisie
  #SBATCH --ntasks=24                   # nombre total de tache MPI
  #SBATCH --ntasks-per-node=24          # nombre de tache MPI par noeud (tous les cœurs)
  #SBATCH --gres=gpu:8                  # nombre de GPU par nœud (tous les GPU)
  #SBATCH --cpus-per-task=1             # nombre de coeurs CPU par tache

• Attention, même si vous travaillez sur une partie seulement du nœud, celui-ci doit être réservé en exclusivité. La totalité du nœud vous est donc facturée.
• 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_mps_multi_gpu_mpi 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 gpu_cuda_mps_multi_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, ou spécifier 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.

La documentation officielle chez NVIDIA.