Turing : notes sur la comptabilité des travaux

Avant de commencer à soumettre, il est important de bien comprendre la politique de l'IDRIS concernant la comptabilité des travaux sur la machine Turing. Celle-ci est en effet basée sur une comptabilisation des ressources réservées en nombre de cœurs par le système, même si à l'exécution seule une fraction de ces ressources est réellement utilisée. Or, dans certains cas, il se peut que vous bloquiez plus de ressources/cœurs que ce que vous pensez utiliser. Cela est notamment dû aux spécificités de l'architecture matérielle et du système de Turing, qui sont explicitées ci-dessous.

La machine Blue Gene/Q de l'IDRIS se compose physiquement de 96 “blocs” constitués d'un I/O node (nécessaire pour booter le bloc) associé à 64 nœuds de calcul ou compute nodes (CN). Lorsqu'un code est sur le point de s'exécuter, le système lui alloue les ressources nécessaires et les lui dédie durant toute la durée d'exécution. Pour ce faire, en fonction du nombre de CN demandés par l'utilisateur, le système va réserver un nombre entier (1,2,16…) de blocs qu'il va agréger entre eux pour former un seul bloc d'exécution. De plus, le système ne peut créer que certaines tailles de blocs : 64, 128, 256, 512, 1024, 2048 ou 4096 CN (en cas de choix différent, le système arrondira cette valeur vers le haut). Il est également possible de ne réserver qu'une fraction des ressources d'un bloc de 64 CN : on parle alors de travail de type sous-bloc. Dans ce cas, les ressources réseau (tore 5D) peuvent être partagées avec d'autres travaux : il peut y avoir un impact sur les performances des communications MPI et sur les entrées/sorties (un seul nœud d'I/O pour 64 nœuds de calcul). Ici aussi, seules certaines tailles de sous-blocs sont autorisées : 1, 2, 4, 8, 16 ou 32 nœuds de calcul.

A l'exécution du code, tout ou partie des ressources réservées pourront être utilisées au libre choix de l'utilisateur, mais la comptabilité se fera sur la base des ressources réservées, quelles aient été ou non utilisées. Ainsi pour toute exécution, le nombre d'heures décomptées sera calculé de la façon suivante : heures décomptées = nbre de cœurs réservés * durée d'exécution. Par exemple, un travail ayant demandé 64 CN et calculant sur 32 processus MPI par CN pendant 1h sera facturé 1024h (64 CN * 16 cœurs par CN * 1h) : cette situation est donc à éviter.

Le nombre de processus par nœud utilisé lors de l'exécution peut aussi avoir des conséquences importantes sur la facturation d'un job. En effet, il est possible de lancer 1, 2, 4, 8, 16, 32 ou 64 processus MPI par nœud de calcul, avec accès à une memoire par processus de respectivement 16 Gio, 8 Gio, 4 Gio, 2 Gio, 1 Gio, 512 Mio ou 256 Mio. Si vous avez besoin de beaucoup de mémoire par processus MPI, que votre application n'est pas multi-threadée ou OpenMP et que vous lancez moins de processus que de cœurs (16 par nœud), vous allez gaspiller des ressources de calcul. Par exemple, pour un travail de 1024 processus MPI avec 4 processus par nœud (et donc 4 Gio par processus), vous devrez demander un bloc de 256 CN. Pour un calcul durant 1 heure, il vous sera donc facturé 4096h (256 CN * 16 cœurs par CN * 1 h). Il faut également rappeler que surcharger un cœur en mettant 2 ou 4 processus par cœur peut être profitable sur une architecture Blue Gene/Q.