Aller au contenu principal

Utilisation de CUDA MPS

Présentation​

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.

Utilisation​

Le service CUDA MPS est disponible 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.

attention

Le nœud devra obligatoirement être réservé de manière exclusive via l'option --exclusive.

  1. Vous pouvez vous inspirer des exemples ci-dessous :
multi_gpu_mpi_mps.slurm
#!/bin/bash
#SBATCH --job-name=multi_gpu_mpi_mps # nom du job
#SBATCH --exclusive                  # on réserve le noeud de manière exclusive 
#SBATCH -C mps                       # activation du service MPS
# Il est possible d'utiliser uniquement des GPU V100 16 Go ou 32 Go
##SBATCH -C mps&v100-16g             # decommenter pour reserver uniquement des GPU V100 16 Go
##SBATCH -C mps&v100-32g             # decommenter pour reserver uniquement des GPU V100 32 Go
# Ici, reservation de 1 noeud avec 4 GPU par noeud et 40 taches MPI :
#SBATCH --nodes=1                    # on demande un noeud
#SBATCH --ntasks-per-node=40         # nombre de taches par noeud
#SBATCH --gres=gpu:4                 # nombre de GPU par noeud (max 4)
# Le nombre de CPU par tache doit etre adapte en fonction de la partition utilisee
# de sorte à ce que ntasks-per-node x cpus-per-tasks = nombre total de coeurs CPU
#SBATCH --cpus-per-task=1            # nombre de CPU par tache (ntasks-per-node x cpus-per-tasks = 40)
# /!\ Attention, "multithread" fait reference à l'hyperthreading dans la terminologie Slurm
#SBATCH --hint=nomultithread         # hyperthreading desactive
#SBATCH --time=00:10:00              # temps maximum d'execution demande (HH:MM:SS)
#SBATCH --output=multi_gpu%j.out     # nom du fichier de sortie (%j est remplacé par le numéro du travail)
#SBATCH --error=multi_gpu%j.out      # nom du fichier d'erreur (ici commun avec la sortie)

# Nettoyage des modules charges en interactif et herites par defaut
module purge

# Chargement des modules
module load ...

# Echo des commandes lancees
set -x

# Le code doit etre compile avec les modules compatibles avec la partition choisie
# Execution du code
srun ./executable_multi_gpu_mpi
  1. Puis soumettre le script via la commande sbatch :
sbatch multi_gpu_mpi_mps.slurm
Attention

Même si vous travaillez sur une partie seulement du nœud, celui-ci doit être réservé en exclusivité pour pouvoir activer le MPS. La totalité du nœud vous est donc facturée.

Remarques :​

  • Nous vous recommandons de compiler et d'exécuter votre code dans un même environnement logiciel en chargeant les mêmes modules.
  • L'option --hint=nomultithread assure la réservation des cœurs physiques (pas d'hyperthreading).
  • La mémoire allouée pour le job est proportionnelle au nombre de cœurs CPU demandés. Par exemple, si vous demandez 1/4 des cœurs CPU physiques d'un nœud, vous aurez accès à 1/4 de sa mémoire RAM. Il est important d'être cohérent avec la configuration des nœuds utilisés pour éviter une surfacturation d'heures, tout en profitant de la mémoire à laquelle vous avez le droit. Vous pouvez consulter notre documentation à ce sujet : Allocation mémoire avec Slurm.
  • Dans ces exemples, on suppose que l'exécutable executable_multi_gpu_mpi se situe dans le répertoire de soumission, c'est-à-dire le répertoire dans lequel on se situe au moment d'utiliser la commande sbatch : la variable $SLURM_SUBMIT_DIR est automatiquement valorisée par Slurm.
  • Le fichier de sortie du calcul se trouvera é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.
  • L'usage de la commande srun est indispensable lorsque vous demandez une exécution multi-tâches. Nous déconseillons l'usage de mpirun sur Jean Zay, seule srun garantit une distribution conforme aux spécifications de ressources demandées dans votre fichier de soumission.
  • Les travaux ont tous des ressources définies par une partition et une "Qualité de Service" QoS (Quality of Service) positionnées par défaut dans Slurm. Vous pouvez en modifier les limites en spécifiant une partition et/ou une QoS comme indiqué dans notre documentation détaillant les partitions et les Qos GPU.
  • 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 travail comme indiqué dans notre documentation détaillant la gestion des heures de calcul pour vous assurer que les heures consommées par vos travaux soient décomptées de la bonne attribution.

Documentation​

La documentation officielle chez NVIDIA.