-gpu

Indique les propriétés des ressources GPU requises par le travail.

Catégories

ressources

Syntaxe

Descriptif

-

Indique que le travail ne définit pas les exigences d'unité de traitement graphique au niveau du travail. Utilisez le trait d'union sans lettre pour définir les exigences de processeur graphique effectives, qui sont définies au niveau du cluster, de la file d'attente ou du profil d'application.

Si une exigence GPU est spécifiée au niveau du cluster, de la file d'attente et du profil d'application, chaque option (num, mode, mps, j_exclusive, gmodel, gtile, gmemet nvlink) de l'exigence GPU est fusionnée séparément. Le niveau de profil d'application remplace le niveau de file d'attente, qui remplace l'exigence de GPU par défaut au niveau du cluster.

Si aucune exigence de processeur graphique n'est définie au niveau du cluster, de la file d'attente ou de l'application, la valeur par défaut est "num=1:mode=shared:mps=no:j_exclusive=no".

num=nb_gpus[ /task | hôte ]

Nombre de processeurs graphiques physiques requis par le travail. Par défaut, le nombre est par hôte. Vous pouvez également indiquer que le nombre est par tâche en spécifiant /task après le nombre.

Si vous avez spécifié que le nombre est par tâche, la configuration de la ressource ngpus_physical dans le fichier lsb.resources est définie sur PER_TASK, ou le paramètre RESOURCE_RESERVE_PER_TASK=Y est défini dans le fichier lsb.params , ce nombre correspond au nombre demandé par tâche.

mode=shared | processus exclusif

Le mode GPU lorsque le travail est en cours d'exécution, shared ou exclusive_process. Le mode par défaut est shared.

Le mode partagé correspond au mode de calcul Nvidia ou AMD DEFAULT . Le mode exclusive_process correspond au mode de calcul Nvidia EXCLUSIVE_PROCESS .

Remarque: ne spécifiez pas exclusive_process lorsque vous utilisez des processeurs graphiques AMD (c'est-à-dire lorsque gvendor=amd est spécifié).

mps=yes[, nocvd ][, shared ] | par_socket[, shared ][, nocvd ] | per_gpu[, shared ][, nocvd ] | no

Active ou désactive le service MPS (Multi-Process Service) de Nvidia pour les processeurs graphiques alloués au travail. L'utilisation efficace de MPS permet au mode EXCLUSIVE_PROCESS de se comporter comme le mode DEFAULT pour tous les clients MPS. MPS permet toujours à plusieurs clients d'utiliser le GPU via le serveur MPS.

Remarque: Pour éviter tout comportement incohérent, n'activez pas les vidages lorsque vous utilisez des processeurs graphiques AMD (c'est-à-dire lorsque gvendor=amd est spécifié). Si le résultat de la fusion des exigences GPU au niveau du cluster, de la file d'attente, de l'application et du travail est gvendor=amd et que mps est activé (par exemple, si gvendor=amd est spécifié au niveau du travail sans spécifier mps=no, mais que mps=yes est spécifié au niveau de l'application, de la file d'attente ou du cluster), LSF ignore l'exigence mps .

MPS est utile pour les GPU de processus partagés et exclusifs, et permet un partage plus efficace des ressources GPU et une meilleure utilisation des GPU. Pour plus d'informations et pour connaître les limitations, voir la documentation Nvidia.

Lors de l'utilisation de MPS, utilisez le mode EXCLUSIVE_PROCESS pour vous assurer qu'un seul serveur MPS utilise le GPU, ce qui fournit une assurance supplémentaire que le serveur MPS est le point d'arbitrage unique entre tous les processus CUDA de ce GPU.

Vous pouvez également activer le partage de démon MPS en ajoutant le mot clé share avec une virgule et sans espace (par exemple, mps=yes,shared active le partage de démon MPS sur l'hôte). Si le partage est activé, tous les travaux soumis par le même utilisateur avec les mêmes besoins en ressources partagent le même démon MPS sur l'hôte, le socket ou le processeur graphique.

LSF démarre les démons MPS par hôte, par socket ou par processeur graphique, en fonction de la valeur du mot clé mps :

Si mps=yes est défini, LSF démarre un démon MPS par hôte et par travail.
Lorsque le partage est activé (c'est-à-dire si mps=yes,shared est défini), LSF démarre un démon MPS par hôte pour tous les travaux soumis par le même utilisateur avec les mêmes besoins en ressources. Ces travaux utilisent tous le même démon MPS sur l'hôte.

Lorsque la variable d'environnement CUDA_VISIBLE_DEVICES est désactivée (c'est-à-dire si mps=yes,nocvd est défini), LSF ne définit pas les variables d'environnement CUDA_VISIBLE_DEVICES<number> pour les tâches, de sorte que LSF MPI ne définit pas CUDA_VISIBLE_DEVICES pour les tâches. LSF définit simplement les variables d'environnement CUDA_VISIBLE_DEVICES<number> pour les tâches, et non CUDA_VISIBLE_DEVICES. LSF MPI convertit les variables d'environnement CUDA_VISIBLE_DEVICES<number> en CUDA_VISIBLE_DEVICES et les définit pour les tâches.
Si mps=per_socket est défini, LSF démarre un démon MPS par socket et par travail. Lorsqu'il est activé avec le partage (c'est-à-dire si mps=per_socket,shared est défini), LSF démarre un démon MPS par socket pour tous les travaux soumis par le même utilisateur avec les mêmes besoins en ressources. Ces travaux utilisent tous le même démon MPS pour le socket.
Si mps=per_gpu est défini, LSF démarre un démon MPS par GPU par travail. Lorsqu'il est activé avec le partage (c'est-à-dire si mps=per_gpu,shared est défini), LSF démarre un démon MPS par processeur graphique pour tous les travaux soumis par le même utilisateur avec les mêmes besoins en ressources. Ces travaux utilisent tous le même démon MPS pour le processeur graphique.

Important: L'utilisation du mode EXCLUSIVE_THREAD avec MPS n'est pas prise en charge et peut entraîner un comportement inattendu.

j_exclusive=yes | non

Indique si les processeurs graphiques alloués peuvent être utilisés par d'autres travaux. Lorsque le mode est défini sur exclusive_process, l'option j_exclusive=yes est définie automatiquement.

aff=yes | non

Indique si une liaison d'affinité GPU-CPU stricte doit être appliquée. Si la valeur est no, LSF assouplit l'affinité GPU tout en maintenant l'affinité de l'unité centrale. Par défaut, aff=yes est défini pour maintenir une liaison d'affinité GPU-CPU stricte.

Remarque: Le paramètre aff=yes est en conflit avec block=yes (distribuez les GPU alloués sous forme de blocs lorsque le nombre de tâches est supérieur au nombre de GPU demandé). Cela est dû au fait que la liaison UC-GPU stricte alloue des GPU aux tâches en fonction de l'ID NUMA de l'UC, qui entre en conflit avec la distribution des GPU alloués sous forme de blocs. Si aff=yes et block=yes sont tous deux spécifiés dans la chaîne des exigences GPU, le paramètre block=yes est prioritaire et la liaison d'affinité UC-GPU stricte est désactivée (c'est-à-dire que aff=no est automatiquement défini).

block=yes | non

Indique s'il convient d'activer la distribution par blocs, c'est-à-dire de distribuer les GPU alloués d'un travail sous forme de blocs lorsque le nombre de tâches est supérieur au nombre de GPU demandé. Si la valeur est yes, LSF distribue tous les processeurs graphiques alloués d'un travail sous forme de blocs lorsque le nombre de tâches est supérieur au nombre de processeurs graphiques demandé. Par défaut, block=no est défini de sorte que les GPU alloués ne soient pas distribués en tant que blocs.

Par exemple, si un travail GPU demande à s'exécuter sur un hôte avec 4 GPU et 40 tâches, la distribution par blocs affecte GPU0 pour les rangs 0 à 9, GPU1 pour les rangs 10 à 19, GPU2 pour les réservoirs 20 à 29 et GPU3 pour les rangs 30 à 39.

Remarque: le paramètre block=yes est en conflit avec aff=yes (liaison d'affinité UC-GPU stricte). Cela est dû au fait que la liaison UC-GPU stricte alloue des GPU aux tâches en fonction de l'ID NUMA de l'UC, qui entre en conflit avec la distribution des GPU alloués sous forme de blocs. Si block=yes et aff=yes sont tous deux spécifiés dans la chaîne des exigences GPU, le paramètre block=yes est prioritaire et la liaison d'affinité UC-GPU stricte est désactivée (c'est-à-dire que aff=no est automatiquement défini).

gpack=yes | non

Pour les travaux en mode partagé uniquement. Indique si la planification des packs doit être activée. Si la valeur est yes, LSF regroupe plusieurs travaux d'unité de traitement graphique en mode partagé dans des unités de traitement graphique allouées. LSF planifie les GPU en mode partagé comme suit:

LSF trie les hôtes candidats (de la plus grande à la plus petite) en fonction du nombre de processeurs graphiques partagés ayant déjà des travaux en cours d'exécution, puis en fonction du nombre de processeurs graphiques non exclusifs.
Si le mot clé order [ ] est défini dans la chaîne des besoins en ressources, après avoir trié order [ ], LSF trie à nouveau les hôtes candidats par la règle gpack (par les GPU partagés qui ont déjà des travaux en cours d'exécution en premier, puis par le nombre de GPU qui ne sont pas exclusifs). La priorité de tri de la règle gpack est supérieure au tri order [ ] .
LSF trie les processeurs graphiques candidats sur chaque hôte (de la plus grande à la plus petite) en fonction du nombre de travaux en cours d'exécution.

Après la planification, le travail du GPU en mode partagé est appliqué au GPU partagé alloué qui est trié en premier, et non à un nouveau GPU partagé.

Si l'affinité d'attribut Docker est activée, l'ordre des hôtes candidats est trié par affinité d'attribut Docker avant le tri par GPU.

Par défaut, gpack=no est défini de sorte que la planification des packs soit désactivée.

gvendor=amd | nvidia

Indique le type de fournisseur du processeur graphique. LSF alloue des GPU avec le type de fournisseur spécifié.

Indiquez amd pour demander des processeurs graphiques AMD ou nvidia pour demander des processeurs graphiques Nvidia.

Par défaut, LSF demande des processeurs graphiques Nvidia.

gmodel=nom_modèle[-taille_mémoire]

Indique les GPU avec le nom de modèle spécifique et, facultativement, la mémoire totale de l'unité de traitement graphique. Par défaut, LSF alloue les GPU avec le même modèle, le cas échéant.

Le mot clé gmodel prend en charge les formats suivants:

gmodel=nom_modèle: Demande des processeurs graphiques avec la marque et le nom de modèle spécifiés (par exemple, TeslaK80).
gmodel=nom_modèle_abrégé: Demande des processeurs graphiques avec un nom de marque spécifique (par exemple, Tesla, Quadro, NVS,) ou le nom du type de modèle (par exemple, K80, P100).
gmodel=nom_modèle-taille_mémoire: Demande des processeurs graphiques avec le nom de marque spécifié et la taille totale de la mémoire du processeur graphique. La taille de la mémoire du processeur graphique est constituée du nombre et de son unité, qui inclut M, G, T, MB, GBet TB (par exemple, 12G).

Pour trouver les noms de modèle de processeur graphique disponibles sur chaque hôte, exécutez les commandes lsload –gpuload, lshosts –gpuou bhosts -gpu . La chaîne de nom de modèle ne contient pas d'espace. En outre, la barre oblique (/) et le trait d'union (-) sont remplacés par le trait de soulignement (_). Par exemple, le nom de modèle GPU "Tesla C2050 / C2070” est converti en "TeslaC2050_C2070dans LSF.

gmem=valeur_mémoire

Indiquez la mémoire du processeur graphique sur chaque processeur graphique requis par le travail. Le format de valeur_mémoire est identique à celui d'une autre valeur de ressource (par exemple,memouswap) dans la section rusage des exigences de ressources de travail (-R).

gtile= ! | num_tile_

Indique le nombre de processeurs graphiques par socket. Spécifiez un nombre pour définir explicitement le nombre de processeurs graphiques par socket sur l'hôte, ou spécifiez un point d'exclamation (!) pour permettre à LSF de calculer automatiquement le nombre, ce qui divise de manière égale les processeurs graphiques par rapport à tous les sockets sur l'hôte. LSF garantit les exigences gtile même pour les travaux d'affinité. Cela signifie que LSF peut ne pas allouer l'affinité de l'unité de traitement graphique aux unités centrales allouées lorsque les exigences gtile ne peuvent pas être satisfaites.

Si le mot clé gtile n'est pas spécifié pour un travail d'affinité, LSF tente d'allouer suffisamment de processeurs graphiques sur les sockets qui ont alloué des processeurs graphiques. S'il n'y a pas assez de processeurs graphiques sur les sockets optimaux, les travaux ne peuvent pas accéder à cet hôte.

Si le mot clé gtile n'est pas spécifié pour un travail sans affinité, LSF tente d'allouer suffisamment de processeurs graphiques sur le même socket. Si cette option n'est pas disponible, LSF peut allouer des processeurs graphiques sur des processeurs graphiques distincts.

nvlink=oui

Obsolète dans LSFversion 10.1 Fix Pack 11. Utilisez le mot clé glink à la place. Active l'application des travaux pour les connexions NVLink entre les GPU. LSF alloue des GPU avec des connexions NVLink en vigueur.

glink=oui

Active l'application des travaux pour les connexions spéciales entre les processeurs graphiques. LSF doit allouer des GPU avec les connexions spéciales spécifiques au fournisseur de GPU.

Si le travail demande des processeurs graphiques AMD, LSF doit allouer des processeurs graphiques avec la connexion xGMI . Si le travail demande des processeurs graphiques Nvidia, LSF doit allouer des processeurs graphiques avec la connexion NVLink.

N'utilisez pas glink avec le mot clé nvlink obsolète.

Par défaut, LSF peut allouer des processeurs graphiques sans connexions spéciales lorsqu'il n'y a pas assez de processeurs graphiques avec ces connexions.

mig=taille_GI[ /taille_GI]

Indique la configuration requise pour les unités Nvidia Multi-Instance GPU (MIG).

Spécifiez la taille de l'instance GPU requise pour le travail MIG. Les tailles d'instance GPU valables sont 1, 2, 3, 4, 7.

En option, spécifiez la taille de l'instance de calcul demandée après la taille de l'instance de GPU spécifiée et une barre oblique (/). La taille de l'instance de calcul demandée doit être inférieure ou égale à la taille de l'instance de GPU demandée. De plus, Nvidia MIG ne prend pas en charge les combinaisons suivantes de taille d'instance de calcul / GPU: 4/3, 7/5, 7/6. S'il n'est pas spécifié, la taille d'instance de calcul par défaut est 1.

La syntaxe de l'exigence GPU dans l'option -gpu est la même que celle du paramètre LSB_GPU_REQ dans le fichier lsf.conf et que celle du paramètre GPU_REQ dans les fichiers lsb.queues et lsb.applications .

Remarque: la sortie bjobs ne s'affiche pasaff=yesmême si vous spécifiez aff=yes dans l'option bsub -gpu .

Si le paramètre GPU_REQ_MERGE est défini en tant que Y ou y dans le fichier lsb.params et qu'une exigence GPU est spécifiée à plusieurs niveaux (au moins deux des exigences par défaut du cluster, de la file d'attente, du profil d'application ou du niveau de travail), chaque option de l'exigence GPU est fusionnée séparément. Le niveau de travail remplace le niveau d'application, qui remplace le niveau de file d'attente, qui remplace l'exigence de processeur graphique de cluster par défaut. Par exemple, si l'option mode de l'exigence GPU est définie sur l'option -gpu et que l'option mps est définie dans la file d'attente, le mode de niveau de travail et la valeur mps de la file d'attente sont utilisés.

Si le paramètre GPU_REQ_MERGE n'est pas défini comme Y ou y dans le fichier lsb.params et qu'une exigence GPU est spécifiée à plusieurs niveaux (au moins deux des exigences par défaut du cluster, de la file d'attente, du profil d'application ou du niveau de travail), l'intégralité de la chaîne d'exigence GPU est remplacée. L'ensemble de la chaîne d'exigences GPU du niveau de travail remplace le niveau d'application, qui remplace le niveau de file d'attente, qui remplace l'exigence GPU par défaut.

Le paramètre esub LSB_SUB4_GPU_REQ modifie la valeur de l'option -gpu .

LSF sélectionne d'abord l'unité de traitement graphique qui répond aux exigences de topologie. Si le mode GPU de l'unité de traitement graphique sélectionnée n'est pas le mode demandé, LSF le remplace par le mode demandé. Par exemple, si LSF alloue une unité de traitement graphique exclusive_process à un travail qui a besoin d'une unité de traitement graphique partagée, LSF fait passer l'unité de traitement graphique en mode partagé avant le démarrage du travail, puis repasse en mode exclusive_process à la fin du travail.

Les exigences du processeur graphique sont converties en exigences de ressources rusage pour le travail. Par exemple, num=2 est converti enrusage[ngpus_physical=2]. Utilisez les commandes bjobs, bhistet bacct pour voir les besoins en ressources fusionnées.

Il peut exister des exigences GPU complexes que l'option bsub -gpu et la syntaxe de paramètre GPU_REQ ne peuvent pas couvrir, y compris des exigences GPU composées (pour des exigences GPU différentes pour des travaux sur des hôtes différents ou pour différentes parties d'un travail parallèle) et des exigences GPU de remplacement (si plusieurs ensembles d'exigences GPU peuvent être acceptables pour l'exécution d'un travail). Pour les exigences GPU complexes, utilisez l'option de commande bsub -R ou le paramètre RES_REQ dans le fichier lsb.applications ou lsb.queues pour définir la chaîne d'exigence de ressource.

Important: Vous pouvez définir les options mode, j_exclusiveet mps uniquement avec l'option -gpu , le paramètre LSB_GPU_REQ dans le fichier lsf.conf ou le paramètre GPU_REQ dans les fichiers lsb.queues ou lsb.applications . Vous ne pouvez pas utiliser ces options avec la chaîne d'exigence de ressource rusage dans l'option de commande bsub -R ou le paramètre RES_REQ dans les fichiers lsb.queues ou lsb.applications .

Exemples

La demande de travail suivante ne remplace pas l'exigence d'unité de traitement graphique effective par les exigences d'unité de traitement graphique de niveau travail. L'exigence d'unité de traitement graphique effective est fusionnée à partir des exigences d'unité de traitement graphique spécifiées au niveau du cluster, de la file d'attente et du profil d'application. Le niveau de profil d'application remplace le niveau de file d'attente, qui remplace l'exigence de GPU par défaut au niveau du cluster.

bsub -gpu - ./app

Le travail suivant requiert 2 GPU en mode EXCLUSIVE_PROCESS et démarre MPS avant d'exécuter le travail.

bsub -gpu "num=2:mode=exclusive_process:mps=yes" ./app

Le travail suivant requiert 2 GPU en mode DEFAULT et les utilise exclusivement. Les deux processeurs graphiques ne peuvent pas être utilisés par d'autres travaux même si le mode est partagé.

bsub -gpu "num=2:mode=shared:j_exclusive=yes" ./app

Le travail suivant utilise 3 GPU en mode DEFAULT et les partage avec d'autres travaux.

bsub -gpu "num=3:mode=shared:j_exclusive=no" ./app

Le travail suivant utilise 4 processeurs graphiques EXCLUSIVE_PROCESS qui ne peuvent pas être utilisés par d'autres travaux. L'option j_exclusive prend par défaut la valeur yes pour ce travail.

bsub -gpu "num=4:mode=exclusive_process" ./app

Le travail suivant requiert deux tâches. Chaque tâche requiert 2 processeurs graphiques EXCLUSIVE_PROCESS sur deux hôtes. Les processeurs graphiques sont alloués dans le même NUMA que l'UC allouée.

bsub -gpu "num=2:mode=exclusive_process" -n2 -R "span[ptile=1] affinity[core(1)]" ./app

Le travail suivant utilise 2 GPU Nvidia MIG avec 3 instances GPU et 2 instances de calcul.

bsub -gpu "num=2:mig=3/2" ./app

Voir aussi

Paramètre LSB_GPU_REQ dans le fichier lsf.conf et paramètre GPU_REQ dans les fichiers lsb.queues et lsb.applications